stdin

../data/rfc/rfc1399.txt-provides information for the Internet community. It does not specify an
../data/rfc/rfc1399.txt-Internet standard.
../data/rfc/rfc1399.txt-
../data/rfc/rfc1399.txt-
../data/rfc/rfc1399.txt-1346 Jones Jun 92 Resource Allocation, Control, and
../data/rfc/rfc1399.txt: Accounting for the Use of Network
../data/rfc/rfc1399.txt- Resources
../data/rfc/rfc1399.txt-
../data/rfc/rfc1399.txt-The purpose of this RFC is to focus discussion on particular challenges
../data/rfc/rfc1399.txt-in large service networks in general, and the International IP Internet
../data/rfc/rfc1399.txt-in particular. No solution discussed in this document is intended as a
--
../data/rfc/rfc2896.txt-
../data/rfc/rfc2896.txt-radiusacct PROTOCOL-IDENTIFIER
../data/rfc/rfc2896.txt- PARAMETERS { }
../data/rfc/rfc2896.txt- ATTRIBUTES { }
../data/rfc/rfc2896.txt- DESCRIPTION
../data/rfc/rfc2896.txt: "RADIUS Accounting Protocol"
../data/rfc/rfc2896.txt- REFERENCE
../data/rfc/rfc2896.txt: "RFC 2139 [RFC2139] defines the Radius Accounting protocol."
../data/rfc/rfc2896.txt- ::= { udp 1813 }
../data/rfc/rfc2896.txt-
../data/rfc/rfc2896.txt- --
../data/rfc/rfc2896.txt- -- Portmapper Functions; Children of sunrpc
../data/rfc/rfc2896.txt- --
--
../data/rfc/rfc2896.txt-
../data/rfc/rfc2896.txt- [RFC2138] Rigney, C., Rubens, A., Simpson, W. and W. Willens,
../data/rfc/rfc2896.txt- "Remote Authentication Dial In User Service (RADIUS)", RFC
../data/rfc/rfc2896.txt- 2138, April 1997.
../data/rfc/rfc2896.txt-
../data/rfc/rfc2896.txt: [RFC2139] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
../data/rfc/rfc2896.txt-
../data/rfc/rfc2896.txt- [RFC2145] Mogul, J., Fielding, R., Gettys, J. and H. Frystyk, "Use
../data/rfc/rfc2896.txt- and interpretation of HTTP version numbers", RFC 2145, May
../data/rfc/rfc2896.txt- 1997.
../data/rfc/rfc2896.txt-
--
../data/rfc/rfc699.txt-
../data/rfc/rfc699.txt-673 Not Issued
../data/rfc/rfc699.txt-
../data/rfc/rfc699.txt-672 Schantz 6 Dec 74 A Multi-Site Data Collection Facility
../data/rfc/rfc699.txt-
../data/rfc/rfc699.txt: Applicability of TIP/TENEX protocols beyond TIP accounting.
../data/rfc/rfc699.txt-
../data/rfc/rfc699.txt-671 Schantz 6 Dec 74 A Note on Reconnection Protocol
../data/rfc/rfc699.txt-
../data/rfc/rfc699.txt- Experience with implementation in RSEXEC context.
../data/rfc/rfc699.txt-
--
../data/rfc/rfc75.txt-8:00 p.m. on Monday, November 16, 1970.
../data/rfc/rfc75.txt-
../data/rfc/rfc75.txt-The purpose of this meeting is to discuss several topics related to
../data/rfc/rfc75.txt-the practical use of the network. I have in mind:
../data/rfc/rfc75.txt-
../data/rfc/rfc75.txt: (a) accounting mechanisms
../data/rfc/rfc75.txt-
../data/rfc/rfc75.txt- (b) documentation distribution
../data/rfc/rfc75.txt-
../data/rfc/rfc75.txt- (c) person-to-person message sending and message storing
../data/rfc/rfc75.txt-
--
../data/rfc/rfc7075.txt-
../data/rfc/rfc7075.txt-5. IANA Considerations
../data/rfc/rfc7075.txt-
../data/rfc/rfc7075.txt- This specification allocates a new AVP code Redirect-Realm (620) in
../data/rfc/rfc7075.txt- the "AVP Codes" registry under "Authentication, Authorization, and
../data/rfc/rfc7075.txt: Accounting (AAA) Parameters".
../data/rfc/rfc7075.txt-
../data/rfc/rfc7075.txt- This specification allocates a new Result-Code value
../data/rfc/rfc7075.txt- DIAMETER_REALM_REDIRECT_INDICATION (3011) in the "Result-Code AVP
../data/rfc/rfc7075.txt- Values (code 268) - Protocol Errors" registry under "Authentication,
../data/rfc/rfc7075.txt: Authorization, and Accounting (AAA) Parameters".
../data/rfc/rfc7075.txt-
../data/rfc/rfc7075.txt-
../data/rfc/rfc7075.txt-
../data/rfc/rfc7075.txt-
../data/rfc/rfc7075.txt-Tsou, et al. Standards Track [Page 8]
--
../data/rfc/rfc129.txt-identified for message traffic routing from an NCP. In
../data/rfc/rfc129.txt-the past it has been said that users can be mobile, i.e.,
../data/rfc/rfc129.txt-log on from different sites, and thus it is the user that
../data/rfc/rfc129.txt-needs identification. In many typical on-line systems the
../data/rfc/rfc129.txt-user first requests a service and then identifies himself
../data/rfc/rfc129.txt:to the service for purposes of accounting, etc. User IDs
../data/rfc/rfc129.txt-can be transmitted after requesting a service and can thus
../data/rfc/rfc129.txt-be elevated above the meaning of socket names.
../data/rfc/rfc129.txt- A program might typically associate the terminals, for
../data/rfc/rfc129.txt-which it is an agent, with the variable part of the identi-
../data/rfc/rfc129.txt-fier, i.e., the particular connection(s). For example,
--
../data/rfc/rfc7326.txt-
../data/rfc/rfc7326.txt-1. Introduction
../data/rfc/rfc7326.txt-
../data/rfc/rfc7326.txt- Network Management is often divided into the five main areas defined
../data/rfc/rfc7326.txt- in the ISO Telecommunications Management Network model: Fault,
../data/rfc/rfc7326.txt: Configuration, Accounting, Performance, and Security Management
../data/rfc/rfc7326.txt- (FCAPS) [X.700]. Not covered by this traditional management model is
../data/rfc/rfc7326.txt- Energy Management, which is rapidly becoming a critical area of
../data/rfc/rfc7326.txt- concern worldwide, as seen in [ISO50001].
../data/rfc/rfc7326.txt-
../data/rfc/rfc7326.txt- This document defines an Energy Management framework for devices
--
../data/rfc/rfc7326.txt- procedures indicating that there should exist multiple
../data/rfc/rfc7326.txt- computerized systems that will poll energy measurements from
../data/rfc/rfc7326.txt- their meters and pricing / source data from their local
../data/rfc/rfc7326.txt- utility. Company A specifies that their CFO (Chief Financial
../data/rfc/rfc7326.txt- Officer) should collect information and summarize it quarterly
../data/rfc/rfc7326.txt: to be sent to an accounting firm to produce carbon accounting
../data/rfc/rfc7326.txt- reporting as required by their local government.
../data/rfc/rfc7326.txt-
../data/rfc/rfc7326.txt- 3. For the purposes of EMAN, the definition herein is the
../data/rfc/rfc7326.txt- preferred meaning of an EnMS. The definition from [ISO50001]
../data/rfc/rfc7326.txt- can be referred to as an ISO Energy Management System
--
../data/rfc/rfc7326.txt- keywords.
../data/rfc/rfc7326.txt-
../data/rfc/rfc7326.txt- An Energy Object can provide a set of keywords that is a list of tags
../data/rfc/rfc7326.txt- that can be used for grouping, summary reporting (within or between
../data/rfc/rfc7326.txt- Energy Management Domains), and searching. Potential examples are
../data/rfc/rfc7326.txt: IT, lobby, HumanResources, Accounting, StoreRoom, CustomerSpace,
../data/rfc/rfc7326.txt- router, phone, floor2, or SoftwareLab.
../data/rfc/rfc7326.txt-
../data/rfc/rfc7326.txt- The specifics of how this tag is represented are left to the MIB
../data/rfc/rfc7326.txt- module or other object definition documents to be based on this
../data/rfc/rfc7326.txt- framework.
--
../data/rfc/rfc7326.txt-Parello, et al. Informational [Page 39]
../data/rfc/rfc7326.txt-
../data/rfc/rfc7326.txt-RFC 7326 EMAN Framework September 2014
../data/rfc/rfc7326.txt-
../data/rfc/rfc7326.txt-
../data/rfc/rfc7326.txt: authorization, audit, and accounting principles to facilitate
../data/rfc/rfc7326.txt- investigations (compromise or benign misconfigurations) or any
../data/rfc/rfc7326.txt- reporting requirements.
../data/rfc/rfc7326.txt-
../data/rfc/rfc7326.txt- The information and control capabilities specified in this framework
../data/rfc/rfc7326.txt- could be exploited, to the detriment of a site or deployment.
--
../data/rfc/rfc7326.txt- o Unauthorized changes to a Power State will disrupt the power
../data/rfc/rfc7326.txt- settings of the different devices and therefore the state of
../data/rfc/rfc7326.txt- functionality of the respective devices.
../data/rfc/rfc7326.txt-
../data/rfc/rfc7326.txt- o Unauthorized changes to the demand history will disrupt proper
../data/rfc/rfc7326.txt: accounting of energy usage.
../data/rfc/rfc7326.txt-
../data/rfc/rfc7326.txt- With respect to data transport, SNMP versions prior to SNMPv3 did not
../data/rfc/rfc7326.txt- include adequate security. Even if the network itself is secure (for
../data/rfc/rfc7326.txt- example, by using IPsec), there is still no secure control over who
../data/rfc/rfc7326.txt- on the secure network is allowed to access and GET/SET
--
../data/rfc/rfc1662.txt-Simpson [Page 11]
../data/rfc/rfc1662.txt-RFC 1662 HDLC-like Framing July 1994
../data/rfc/rfc1662.txt-
../data/rfc/rfc1662.txt-
../data/rfc/rfc1662.txt- mark idle (continuous ones), particularly those that calculate
../data/rfc/rfc1662.txt: accounting based on periods of bit activity. When mark idle is used
../data/rfc/rfc1662.txt- on a bit-synchronous link, the implementation MUST ensure at least 15
../data/rfc/rfc1662.txt- consecutive "1" bits between Flags during the idle period, and that
../data/rfc/rfc1662.txt- the Flag Sequence is always generated at the beginning of a frame
../data/rfc/rfc1662.txt- after an idle period.
../data/rfc/rfc1662.txt-
--
../data/rfc/rfc7678.txt- enumerates the information that needs to be provisioned on a customer
../data/rfc/rfc7678.txt- edge router to support a list of transition techniques based on
../data/rfc/rfc7678.txt- tunneling IPv4 in IPv6, with a view to defining reusable components
../data/rfc/rfc7678.txt- for a reasonable transition path between these techniques. To the
../data/rfc/rfc7678.txt- extent that the provisioning is done dynamically, Authentication,
../data/rfc/rfc7678.txt: Authorization, and Accounting (AAA) support is needed to provide the
../data/rfc/rfc7678.txt- information to the network server responsible for passing the
../data/rfc/rfc7678.txt- information to the customer equipment. This document specifies
../data/rfc/rfc7678.txt- Diameter (RFC 6733) Attribute-Value Pairs (AVPs) to be used for that
../data/rfc/rfc7678.txt- purpose.
../data/rfc/rfc7678.txt-
--
../data/rfc/rfc7678.txt- Each technique requires the provisioning of some subscriber-specific
../data/rfc/rfc7678.txt- information on the customer edge device. The provisioning may be by
../data/rfc/rfc7678.txt- DHCPv6 [RFC3315] or by some other method. This document is
../data/rfc/rfc7678.txt- indifferent to the specific provisioning technique used but assumes a
../data/rfc/rfc7678.txt- deployment in which that information is managed by AAA
../data/rfc/rfc7678.txt: (Authentication, Authorization, and Accounting) servers. It further
../data/rfc/rfc7678.txt- assumes that this information is delivered to intermediate network
../data/rfc/rfc7678.txt- nodes for onward provisioning using the Diameter protocol [RFC6733].
../data/rfc/rfc7678.txt-
../data/rfc/rfc7678.txt- As described below, in the particular case where the Lightweight
../data/rfc/rfc7678.txt- 4over6 (lw4o6) [RFC7596] transition method has been deployed, per-
--
../data/rfc/rfc4818.txt-Salowey & Droms Standards Track [Page 3]
../data/rfc/rfc4818.txt-
../data/rfc/rfc4818.txt-RFC 4818 Delegated-IPv6-Prefix Attribute April 2007
../data/rfc/rfc4818.txt-
../data/rfc/rfc4818.txt-
../data/rfc/rfc4818.txt: The Delegated-IPv6-Prefix attribute MAY appear in an Accounting-
../data/rfc/rfc4818.txt- Request packet.
../data/rfc/rfc4818.txt-
../data/rfc/rfc4818.txt- The Delegated-IPv6-Prefix MUST NOT appear in any other RADIUS
../data/rfc/rfc4818.txt- packets.
../data/rfc/rfc4818.txt-
--
../data/rfc/rfc4818.txt-
../data/rfc/rfc4818.txt- The following table provides a guide to which attributes may be found
../data/rfc/rfc4818.txt- in which kinds of packets, and in what quantity.
../data/rfc/rfc4818.txt-
../data/rfc/rfc4818.txt- +-------------------------------------------------------------------+
../data/rfc/rfc4818.txt: | Request Accept Reject Challenge Accounting # Attribute |
../data/rfc/rfc4818.txt- | Request |
../data/rfc/rfc4818.txt- | 0+ 0+ 0 0 0+ 123 Delegated-IPv6- |
../data/rfc/rfc4818.txt- | Prefix |
../data/rfc/rfc4818.txt- +-------------------------------------------------------------------+
../data/rfc/rfc4818.txt-
--
../data/rfc/rfc4818.txt-
../data/rfc/rfc4818.txt-RFC 4818 Delegated-IPv6-Prefix Attribute April 2007
../data/rfc/rfc4818.txt-
../data/rfc/rfc4818.txt-
../data/rfc/rfc4818.txt- The text in this specification describing the applicability of the
../data/rfc/rfc4818.txt: Delegated-IPv6-Prefix attribute for RADIUS Accounting-Request applies
../data/rfc/rfc4818.txt: to Diameter Accounting-Request [6] as well.
../data/rfc/rfc4818.txt-
../data/rfc/rfc4818.txt- The AVP flag rules [5] for the Delegated-IPv6-Prefix attribute are:
../data/rfc/rfc4818.txt-
../data/rfc/rfc4818.txt- +---------------------+
../data/rfc/rfc4818.txt- | AVP Flag rules |
--
../data/rfc/rfc6374.txt- o The LM protocol can perform two distinct kinds of loss
../data/rfc/rfc6374.txt- measurement: it can measure the loss of specially generated test
../data/rfc/rfc6374.txt- messages in order to infer the approximate data-plane loss level
../data/rfc/rfc6374.txt- (inferred measurement) or it can directly measure data-plane
../data/rfc/rfc6374.txt- packet loss (direct measurement). Direct measurement provides
../data/rfc/rfc6374.txt: perfect loss accounting, but may require specialized hardware
../data/rfc/rfc6374.txt- support and is only applicable to some LSP types. Inferred
../data/rfc/rfc6374.txt: measurement provides only approximate loss accounting but is
../data/rfc/rfc6374.txt- generally applicable.
../data/rfc/rfc6374.txt-
../data/rfc/rfc6374.txt-
../data/rfc/rfc6374.txt-
../data/rfc/rfc6374.txt-
--
../data/rfc/rfc6374.txt-
../data/rfc/rfc6374.txt-RFC 6374 MPLS Loss and Delay Measurement September 2011
../data/rfc/rfc6374.txt-
../data/rfc/rfc6374.txt-
../data/rfc/rfc6374.txt- Direct LM has the advantage of being able to provide perfect loss
../data/rfc/rfc6374.txt: accounting when it is available. There are, however, several
../data/rfc/rfc6374.txt- constraints associated with direct LM.
../data/rfc/rfc6374.txt-
../data/rfc/rfc6374.txt- For accurate direct LM to occur, packets must not be sent between the
../data/rfc/rfc6374.txt- time the transmit count for an outbound LM message is determined and
../data/rfc/rfc6374.txt- the time the message is actually transmitted. Similarly, packets
--
../data/rfc/rfc8921.txt- solicits features supported by the following functional blocks:
../data/rfc/rfc8921.txt-
../data/rfc/rfc8921.txt- * Network provisioning (including order activation, Network
../data/rfc/rfc8921.txt- Planning, etc.)
../data/rfc/rfc8921.txt-
../data/rfc/rfc8921.txt: * Authentication, authorization, and accounting (AAA)
../data/rfc/rfc8921.txt-
../data/rfc/rfc8921.txt- * Network and service management (performance measurement and
../data/rfc/rfc8921.txt- assessment, fault detection, etc.)
../data/rfc/rfc8921.txt-
../data/rfc/rfc8921.txt- * Sales-related functional blocks (e.g., billing, invoice
--
../data/rfc/rfc4988.txt-
../data/rfc/rfc4988.txt- [rfc2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
../data/rfc/rfc4988.txt- 2131, March 1997.
../data/rfc/rfc4988.txt-
../data/rfc/rfc4988.txt- [rfc3957] Perkins, C. and P. Calhoun, "Authentication,
../data/rfc/rfc4988.txt: Authorization, and Accounting (AAA) Registration Keys
../data/rfc/rfc4988.txt- for Mobile IPv4", RFC 3957, March 2005.
../data/rfc/rfc4988.txt-
../data/rfc/rfc4988.txt-
../data/rfc/rfc4988.txt-
../data/rfc/rfc4988.txt-
--
../data/rfc/rfc8583.txt- information to non-peer nodes requires a transitive-trust model.
../data/rfc/rfc8583.txt-
../data/rfc/rfc8583.txt-9. IANA Considerations
../data/rfc/rfc8583.txt-
../data/rfc/rfc8583.txt- IANA has registered three new AVP codes in the "Authentication,
../data/rfc/rfc8583.txt: Authorization, and Accounting (AAA) Parameters" registry; see
../data/rfc/rfc8583.txt- Sections 7.1, 7.2, and 7.3.
../data/rfc/rfc8583.txt-
../data/rfc/rfc8583.txt-
../data/rfc/rfc8583.txt-
../data/rfc/rfc8583.txt-Campbell, et al. Standards Track [Page 16]
--
../data/rfc/rfc436.txt-supports a subset of the Remote Job Entry Protocol of RFC #407. This
../data/rfc/rfc436.txt-document includes enough information to allow the user to gain access
../data/rfc/rfc436.txt-to, and use the more basic function of UCSB's RJS. An RFC containing
../data/rfc/rfc436.txt-more detailed documentation will be forthcoming shortly.
../data/rfc/rfc436.txt-
../data/rfc/rfc436.txt: The accounting parameters needed to login to RJS are a userid and a
../data/rfc/rfc436.txt-password, each consisting of one to eight alphameric characters, the
../data/rfc/rfc436.txt-first of which must be alphabetic. The userid is, at present,
../data/rfc/rfc436.txt-completely arbitrary. The password is arbitrary the first time it is
../data/rfc/rfc436.txt-used with a particular userid; in subsequent logins with that userid,
../data/rfc/rfc436.txt-the same password must appear. Eventually, users will be assigned
--
../data/rfc/rfc6813.txt-
../data/rfc/rfc6813.txt- The NEA Asokan Attack is a variation on an attack described in a 2002
../data/rfc/rfc6813.txt- paper written by Asokan, Niemi, and Nyberg [1]. Figure 1 depicts one
../data/rfc/rfc6813.txt- version of the original Asokan attack. This attack involves tricking
../data/rfc/rfc6813.txt- an authorized user into authenticating to a decoy Authentication,
../data/rfc/rfc6813.txt: Authorization, and Accounting (AAA) server, which forwards the
../data/rfc/rfc6813.txt- authentication protocol from one tunnel to another, tricking the real
../data/rfc/rfc6813.txt- AAA server into believing these messages originated from the
../data/rfc/rfc6813.txt- attacker-controlled machine. As a result, the real AAA server grants
../data/rfc/rfc6813.txt- access to the attacker-controlled machine.
../data/rfc/rfc6813.txt-
--
../data/rfc/rfc3689.txt- access to emergency telecommunications services. Any mechanism
../data/rfc/rfc3689.txt- for providing such authorization beyond closed private networks
../data/rfc/rfc3689.txt- SHOULD meet IETF Security Area criterion (e.g., clear-text
../data/rfc/rfc3689.txt- passwords would not generally be acceptable). Authorization
../data/rfc/rfc3689.txt- protects network resources from excessive use, from abuse, and
../data/rfc/rfc3689.txt: might also support billing and accounting for the offered service.
../data/rfc/rfc3689.txt-
../data/rfc/rfc3689.txt- Such authorization mechanisms SHOULD be flexible enough to provide
../data/rfc/rfc3689.txt- various levels of restriction and authorization depending on the
../data/rfc/rfc3689.txt- expectations of a particular service or customer.
../data/rfc/rfc3689.txt-
--
../data/rfc/rfc3689.txt- not specify solutions nor is it to be confused with requirements.
../data/rfc/rfc3689.txt- Subsequent documents that articulate a more specific set of
../data/rfc/rfc3689.txt- requirements for a particular service may make a statement about the
../data/rfc/rfc3689.txt- following issues.
../data/rfc/rfc3689.txt-
../data/rfc/rfc3689.txt: 1) Accounting
../data/rfc/rfc3689.txt-
../data/rfc/rfc3689.txt: Accounting represents a method of tracking actual usage of a
../data/rfc/rfc3689.txt- service. We assume that the usage of any service better than best
../data/rfc/rfc3689.txt- effort will be tracked and subsequently billed to the user.
../data/rfc/rfc3689.txt: Accounting is not addressed as a general requirement for ETS.
../data/rfc/rfc3689.txt- However, solutions used to realize ETS should not preclude an
../data/rfc/rfc3689.txt: accounting mechanism.
../data/rfc/rfc3689.txt-
../data/rfc/rfc3689.txt- 2) Admission Control
../data/rfc/rfc3689.txt-
../data/rfc/rfc3689.txt- The requirements of section 3 discuss labels and security. Those
../data/rfc/rfc3689.txt- developing solutions should understand that the ability labels
--
../data/rfc/rfc6538.txt- other approaches was published in [MOBILITY-COMPARISON].
../data/rfc/rfc6538.txt-
../data/rfc/rfc6538.txt-9. Security Considerations
../data/rfc/rfc6538.txt-
../data/rfc/rfc6538.txt- This document is an informational survey of HIP-related research and
../data/rfc/rfc6538.txt: experience. Space precludes a full accounting of all security issues
../data/rfc/rfc6538.txt- associated with the approaches surveyed here, but the individually
../data/rfc/rfc6538.txt- referenced documents may discuss security considerations for their
../data/rfc/rfc6538.txt- respective protocol component. HIP security considerations for the
../data/rfc/rfc6538.txt- base HIP protocol can be found in Section 8 of [RFC5201].
../data/rfc/rfc6538.txt-
--
../data/rfc/rfc1391.txt-
../data/rfc/rfc1391.txt- For those who could not attend a meeting but would like a copy of the
../data/rfc/rfc1391.txt- Proceedings send a check for $35 (made payable to CNRI) to:
../data/rfc/rfc1391.txt-
../data/rfc/rfc1391.txt- Corporation for National Research Initiatives
../data/rfc/rfc1391.txt: Attn: Accounting Department - IETF Proceedings
../data/rfc/rfc1391.txt- 1895 Preston White Drive, Suite 100
../data/rfc/rfc1391.txt- Reston, VA 22091
../data/rfc/rfc1391.txt-
../data/rfc/rfc1391.txt- Please indicate which meeting Proceedings you would like to receive
../data/rfc/rfc1391.txt- by specifying the meeting date (e.g., July 1992) or meeting number
--
../data/rfc/rfc1010.txt- 1-149 Unassigned [JBP]
../data/rfc/rfc1010.txt- 150 Xerox NS IDP [102,XEROX]
../data/rfc/rfc1010.txt- 151 Unassigned [JBP]
../data/rfc/rfc1010.txt- 152 PARC Universal Protocol [7,XEROX]
../data/rfc/rfc1010.txt- 153 TIP Status Reporting [JGH]
../data/rfc/rfc1010.txt: 154 TIP Accounting [JGH]
../data/rfc/rfc1010.txt- 155 Internet Protocol [regular] [80,JBP]
../data/rfc/rfc1010.txt- 156-158 Internet Protocol [experimental] [80,JBP]
../data/rfc/rfc1010.txt- 159 Figleaf Link [JBW1]
../data/rfc/rfc1010.txt- 160-194 Unassigned [JBP]
../data/rfc/rfc1010.txt- 195 ISO-IP [52,RXM]
--
../data/rfc/rfc2676.txt- it is also important for the algorithm to account for the amount of
../data/rfc/rfc2676.txt- resources the network has to allocate to support a new flow. In
../data/rfc/rfc2676.txt- general, the network prefers to select the "cheapest" path among all
../data/rfc/rfc2676.txt- paths suitable for a new flow, and it may even decide not to accept a
../data/rfc/rfc2676.txt- new flow for which a feasible path exists, if the cost of the path is
../data/rfc/rfc2676.txt: deemed too high. Accounting for these aspects involves several
../data/rfc/rfc2676.txt- metrics on which the path selection process is based. They include:
../data/rfc/rfc2676.txt-
../data/rfc/rfc2676.txt- - Link available bandwidth: As mentioned earlier, we currently
../data/rfc/rfc2676.txt- assume that most QoS requirements are derivable from a rate-
../data/rfc/rfc2676.txt- related quantity, termed "bandwidth." We further assume that
--
../data/rfc/rfc2676.txt- proceeds. For simplicity, we first describe the simpler case where
../data/rfc/rfc2676.txt- all edges count as "hops," and later explain how zero-hop edges are
../data/rfc/rfc2676.txt- handled. Zero-hop edges arise in the case of transit networks
../data/rfc/rfc2676.txt- vertices, where only one of the two incoming and outgoing edges
../data/rfc/rfc2676.txt- should be counted in the hop count computation, as they both
../data/rfc/rfc2676.txt: correspond to the same physical hop. Accounting for this aspect
../data/rfc/rfc2676.txt- requires distinguishing between network and router nodes, and the
../data/rfc/rfc2676.txt- steps involved are detailed later in this section as well as in the
../data/rfc/rfc2676.txt- pseudo-code of Appendix A.
../data/rfc/rfc2676.txt-
../data/rfc/rfc2676.txt- When the algorithm is invoked, the routing table is first initialized
--
../data/rfc/rfc5810.txt- Before the transition to the association phase, the FEM will have
../data/rfc/rfc5810.txt- established contact with a CEM component. Initialization of the
../data/rfc/rfc5810.txt- ForCES interface will have completed, and authentication as well as
../data/rfc/rfc5810.txt- capability discovery may be complete. Both the FE and CE would have
../data/rfc/rfc5810.txt- the necessary information for connecting to each other for
../data/rfc/rfc5810.txt: configuration, accounting, identification, and authentication
../data/rfc/rfc5810.txt- purposes. To summarize, at the completion of this stage both sides
../data/rfc/rfc5810.txt- have all the necessary protocol parameters such as timers, etc. The
../data/rfc/rfc5810.txt- Fl reference point may continue to operate during the association
../data/rfc/rfc5810.txt- phase and may be used to force a disassociation of an FE or CE. The
../data/rfc/rfc5810.txt- specific interactions of the CEM and the FEM that are part of the
--
../data/rfc/rfc3292.txt- information concerning a single connection. Each connection is
../data/rfc/rfc3292.txt- specified by its input port and Input Label which are specified in
../data/rfc/rfc3292.txt- the Input Port and Input Label fields of each Activity Record.
../data/rfc/rfc3292.txt-
../data/rfc/rfc3292.txt- Two forms of activity detection are supported. If the switch
../data/rfc/rfc3292.txt: supports per connection traffic accounting, the current value of the
../data/rfc/rfc3292.txt- traffic counter for each specified connection MUST be returned. The
../data/rfc/rfc3292.txt- units of traffic counted are not specified but will typically be
../data/rfc/rfc3292.txt- either cells or frames. The controller MUST compare the traffic
../data/rfc/rfc3292.txt- counts returned in the message with previous values for each of the
../data/rfc/rfc3292.txt- specified connections to determine whether each connection has been
../data/rfc/rfc3292.txt- active in the intervening period. If the switch does not support per
../data/rfc/rfc3292.txt: connection traffic accounting, but is capable of detecting per
../data/rfc/rfc3292.txt- connection activity by some other unspecified means, the result may
../data/rfc/rfc3292.txt- be indicated for each connection using the Flags field. The
../data/rfc/rfc3292.txt- Connection Activity message is:
../data/rfc/rfc3292.txt-
../data/rfc/rfc3292.txt- Message Type = 48
--
../data/rfc/rfc5945.txt-RFC 5945 RSVP Proxy Approaches October 2010
../data/rfc/rfc5945.txt-
../data/rfc/rfc5945.txt-
../data/rfc/rfc5945.txt- on-path admission control can be offered to VoD services over
../data/rfc/rfc5945.txt- broadband aggregation networks without network or VoD pump upgrade.
../data/rfc/rfc5945.txt: Those include accurate bandwidth accounting regardless of topology
../data/rfc/rfc5945.txt- (hub-and-spoke, ring, mesh, star, arbitrary combinations) and dynamic
../data/rfc/rfc5945.txt- adjustment to any change in topology (such as failure, routing
../data/rfc/rfc5945.txt- change, additional links, etc.).
../data/rfc/rfc5945.txt-
../data/rfc/rfc5945.txt-A.2. RSVP-Based Voice/Video Connection Admission Control (CAC) in
--
../data/rfc/rfc4821.txt- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
../data/rfc/rfc4821.txt- 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
../data/rfc/rfc4821.txt- 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
../data/rfc/rfc4821.txt- 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9
../data/rfc/rfc4821.txt- 5. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
../data/rfc/rfc4821.txt: 5.1. Accounting for Header Sizes . . . . . . . . . . . . . . . 10
../data/rfc/rfc4821.txt- 5.2. Storing PMTU Information . . . . . . . . . . . . . . . . . 11
../data/rfc/rfc4821.txt: 5.3. Accounting for IPsec . . . . . . . . . . . . . . . . . . . 12
../data/rfc/rfc4821.txt- 5.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 12
../data/rfc/rfc4821.txt- 6. Common Packetization Properties . . . . . . . . . . . . . . . 13
../data/rfc/rfc4821.txt- 6.1. Mechanism to Detect Loss . . . . . . . . . . . . . . . . . 13
../data/rfc/rfc4821.txt- 6.2. Generating Probes . . . . . . . . . . . . . . . . . . . . 13
../data/rfc/rfc4821.txt- 7. The Probing Method . . . . . . . . . . . . . . . . . . . . . . 14
--
../data/rfc/rfc4821.txt- control state machines.
../data/rfc/rfc4821.txt-
../data/rfc/rfc4821.txt- Note that this layering approach is a direct extension of the advice
../data/rfc/rfc4821.txt- in the current PMTUD specifications in RFC 1191 and RFC 1981.
../data/rfc/rfc4821.txt-
../data/rfc/rfc4821.txt:5.1. Accounting for Header Sizes
../data/rfc/rfc4821.txt-
../data/rfc/rfc4821.txt- The way in which PLPMTUD operates across multiple layers requires a
../data/rfc/rfc4821.txt: mechanism for accounting header sizes at all layers between IP and
../data/rfc/rfc4821.txt- the Packetization Layer (inclusive). When transmitting non-probe
../data/rfc/rfc4821.txt- packets, it is sufficient for the Packetization Layer to ensure an
../data/rfc/rfc4821.txt- upper bound on final IP packet size, so as not to exceed the current
../data/rfc/rfc4821.txt-
../data/rfc/rfc4821.txt-
--
../data/rfc/rfc4821.txt- [RFC2460][RFC3697] as the local representation of a path. Such an
../data/rfc/rfc4821.txt- approach could theoretically result in the use of optimally sized
../data/rfc/rfc4821.txt- packets on a per-flow basis, providing finer granularity than MTU
../data/rfc/rfc4821.txt- values maintained on a per-destination basis.
../data/rfc/rfc4821.txt-
../data/rfc/rfc4821.txt:5.3. Accounting for IPsec
../data/rfc/rfc4821.txt-
../data/rfc/rfc4821.txt- This document does not take a stance on the placement of IP Security
../data/rfc/rfc4821.txt- (IPsec) [RFC2401], which logically sits between IP and the
../data/rfc/rfc4821.txt- Packetization Layer. A PLPMTUD implementation can treat IPsec either
../data/rfc/rfc4821.txt- as part of IP or as part of the Packetization Layer, as long as the
../data/rfc/rfc4821.txt: accounting is consistent within the implementation. If IPsec is
../data/rfc/rfc4821.txt- treated as part of the IP layer, then each security association to a
../data/rfc/rfc4821.txt- remote node may need to be treated as a separate path. If IPsec is
../data/rfc/rfc4821.txt- treated as part of the Packetization Layer, the IPsec header size
../data/rfc/rfc4821.txt- MUST be included in the Packetization Layer's header size
../data/rfc/rfc4821.txt- calculations.
--
../data/rfc/rfc7980.txt-
../data/rfc/rfc7980.txt-7.3. Network-External Dependencies
../data/rfc/rfc7980.txt-
../data/rfc/rfc7980.txt- Some dependencies are on elements outside the actual network, for
../data/rfc/rfc7980.txt- example, on an external NTP clock source or an Authentication,
../data/rfc/rfc7980.txt: Authorization, and Accounting (AAA) server. Again, a trade-off is
../data/rfc/rfc7980.txt- made: in the example of AAA used for login authentication, we reduce
../data/rfc/rfc7980.txt- the configuration (state) on each node (in particular, user-specific
../data/rfc/rfc7980.txt- configuration), but we add an external dependency on a AAA server.
../data/rfc/rfc7980.txt- In networks with many administrators, a AAA server is clearly the
../data/rfc/rfc7980.txt- only manageable way to track all administrators. But, it comes at
--
../data/rfc/rfc4284.txt- sent to the peer in an EAP-Request/Identity message by appending it
../data/rfc/rfc4284.txt- after the displayable message and a NUL character.
../data/rfc/rfc4284.txt-
../data/rfc/rfc4284.txt- This mechanism may assist the peer in selecting a credential and
../data/rfc/rfc4284.txt- associated NAI, or in formatting the NAI [RFC4282] to facilitate
../data/rfc/rfc4284.txt: routing of Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc4284.txt- messages to the home AAA server. If there are several mediating
../data/rfc/rfc4284.txt- networks available, the peer can influence which one is used.
../data/rfc/rfc4284.txt-
../data/rfc/rfc4284.txt- Exactly how the selection is made by the peer depends largely on the
../data/rfc/rfc4284.txt- peer's local policy and configuration, and is outside the scope of
--
../data/rfc/rfc2211.txt- Controlled-load service modules provide QoS control for traffic
../data/rfc/rfc2211.txt- conforming to the TSpec given at setup time. The TSpec's token
../data/rfc/rfc2211.txt- bucket parameters require that traffic must obey the rule that over
../data/rfc/rfc2211.txt- all time periods, the amount of data sent does not exceed rT+b, where
../data/rfc/rfc2211.txt- r and b are the token bucket parameters and T is the length of the
../data/rfc/rfc2211.txt: time period. For the purposes of this accounting, links must count
../data/rfc/rfc2211.txt- packets that are smaller than the minimal policing unit m to be of
../data/rfc/rfc2211.txt- size m. Packets that arrive at an element and cause a violation of
../data/rfc/rfc2211.txt- the the rT+b bound are considered nonconformant.
../data/rfc/rfc2211.txt-
../data/rfc/rfc2211.txt- Additionally, packets bigger than the outgoing link MTU are
--
../data/rfc/rfc7744.txt- mixture of these topologies may be deployed to collect the metering
../data/rfc/rfc7744.txt- information. Drive-by metering is one of the most current solutions
../data/rfc/rfc7744.txt- deployed for collection of gas and water meters.
../data/rfc/rfc7744.txt-
../data/rfc/rfc7744.txt- Various stakeholders have a claim on the metering data. Utility
../data/rfc/rfc7744.txt: companies need the data for accounting, the metering equipment may be
../data/rfc/rfc7744.txt- operated by a third-party service operator who needs to maintain it,
../data/rfc/rfc7744.txt- and the equipment is installed in the premises of the consumers,
../data/rfc/rfc7744.txt- measuring their consumption, which entails privacy questions.
../data/rfc/rfc7744.txt-
../data/rfc/rfc7744.txt-2.5.1. Drive-By Metering
--
../data/rfc/rfc5441.txt- been explicitly listed as a requirement in [RFC4105] and [RFC4216].
../data/rfc/rfc5441.txt- In the case of a TE LSP reoptimization request, the reoptimization
../data/rfc/rfc5441.txt- procedure defined in [RFC5440] applies when the path in use (if
../data/rfc/rfc5441.txt- available on the head-end) is provided as part of the path
../data/rfc/rfc5441.txt- computation request so that the PCEs involved in the reoptimization
../data/rfc/rfc5441.txt: request can avoid double bandwidth accounting.
../data/rfc/rfc5441.txt-
../data/rfc/rfc5441.txt-12. Path Computation Failure
../data/rfc/rfc5441.txt-
../data/rfc/rfc5441.txt- If a PCE requires to relay a path computation request according to
../data/rfc/rfc5441.txt- the BRPC procedure defined in this document to a downstream PCE and
--
../data/rfc/rfc2654.txt- cn: Barbara Jensen
../data/rfc/rfc2654.txt- cn: Barbara J Jensen
../data/rfc/rfc2654.txt- cn: Babs Jensen
../data/rfc/rfc2654.txt- sn: Jensen
../data/rfc/rfc2654.txt- uid: bjensen
../data/rfc/rfc2654.txt: dn: cn=Bjorn Jensen, ou=Accounting, o=Ace Industry, c=US
../data/rfc/rfc2654.txt- objectclass: top
../data/rfc/rfc2654.txt- objectclass: person
../data/rfc/rfc2654.txt- objectclass: organizationalPerson
../data/rfc/rfc2654.txt- cn: Bjorn Jensen
../data/rfc/rfc2654.txt- sn: Jensen
../data/rfc/rfc2654.txt: title: Accounting manager
../data/rfc/rfc2654.txt- dn: cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US
../data/rfc/rfc2654.txt- objectclass: top
../data/rfc/rfc2654.txt- objectclass: person
../data/rfc/rfc2654.txt- objectclass: organizationalPerson
../data/rfc/rfc2654.txt- cn: Gern Jensen
--
../data/rfc/rfc2654.txt- -4/Horatio
../data/rfc/rfc2654.txt- -4/N
../data/rfc/rfc2654.txt- sn: */Jensen
../data/rfc/rfc2654.txt- title: 1/product
../data/rfc/rfc2654.txt- -1-2/manager
../data/rfc/rfc2654.txt: -1/accounting
../data/rfc/rfc2654.txt- -3,4/testpilot
../data/rfc/rfc2654.txt- END Index-Info
../data/rfc/rfc2654.txt-
../data/rfc/rfc2654.txt-5.1.2 "tag" consistency based full update
../data/rfc/rfc2654.txt-
--
../data/rfc/rfc2654.txt- -4/N
../data/rfc/rfc2654.txt- sn: */Jensen
../data/rfc/rfc2654.txt-
../data/rfc/rfc2654.txt- title: 1/product
../data/rfc/rfc2654.txt- -1-2/manager
../data/rfc/rfc2654.txt: -1/accounting
../data/rfc/rfc2654.txt- -3,4/testpilot
../data/rfc/rfc2654.txt- END Index-Info
../data/rfc/rfc2654.txt-
../data/rfc/rfc2654.txt-5.1.3 "unique" consistency based full update
../data/rfc/rfc2654.txt-
--
../data/rfc/rfc2654.txt- sn: FULL
../data/rfc/rfc2654.txt- title: TOKEN
../data/rfc/rfc2654.txt- END IO-Schema
../data/rfc/rfc2654.txt- BEGIN Index-Info
../data/rfc/rfc2654.txt- dn: 1/cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US
../data/rfc/rfc2654.txt: -2/cn=Bjorn Jensen, ou=Accounting, o=Ace Industry, c=US
../data/rfc/rfc2654.txt- -3/cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US
../data/rfc/rfc2654.txt- -4/cn=Horatio Jensen, ou=Product Testing, o=Ace Industry, c=US
../data/rfc/rfc2654.txt- cn: 1/Barbara
../data/rfc/rfc2654.txt- -1/J
../data/rfc/rfc2654.txt- -1/Babs
--
../data/rfc/rfc2654.txt- -4/Horatio
../data/rfc/rfc2654.txt- -4/N
../data/rfc/rfc2654.txt- sn: */Jensen
../data/rfc/rfc2654.txt- title: 1/product
../data/rfc/rfc2654.txt- -1-2/manager
../data/rfc/rfc2654.txt: -1/accounting
../data/rfc/rfc2654.txt- -3,4/testpilot
../data/rfc/rfc2654.txt- END Index-Info
../data/rfc/rfc2654.txt-
../data/rfc/rfc2654.txt-
../data/rfc/rfc2654.txt-
--
../data/rfc/rfc2654.txt- objectclass: organizationalPerson
../data/rfc/rfc2654.txt- cn: Bo Didley
../data/rfc/rfc2654.txt- sn: Didley
../data/rfc/rfc2654.txt- title: Policy Maker
../data/rfc/rfc2654.txt- # Delete an existing entry
../data/rfc/rfc2654.txt: dn: cn=Bjorn Jensen, ou=Accounting, o=Ace Industry, c=US
../data/rfc/rfc2654.txt- changetype: delete
../data/rfc/rfc2654.txt- # Modify all other entries: adding an additional locality value
../data/rfc/rfc2654.txt- dn: cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US
../data/rfc/rfc2654.txt- changetype: modify
../data/rfc/rfc2654.txt- add: locality
--
../data/rfc/rfc2654.txt- END Add Block
../data/rfc/rfc2654.txt- BEGIN Delete Block
../data/rfc/rfc2654.txt- cn: 1/Bjorn
../data/rfc/rfc2654.txt- -1/Jensen
../data/rfc/rfc2654.txt- sn: 1/Jensen
../data/rfc/rfc2654.txt: title: 1/Accounting
../data/rfc/rfc2654.txt- -1/Manager
../data/rfc/rfc2654.txt- END Delete Block
../data/rfc/rfc2654.txt- BEGIN Update Block
../data/rfc/rfc2654.txt- BEGIN Old
../data/rfc/rfc2654.txt- cn: 1/Barbara
--
../data/rfc/rfc2654.txt- END Add Block
../data/rfc/rfc2654.txt- BEGIN Delete Block
../data/rfc/rfc2654.txt- cn: 2/Bjorn
../data/rfc/rfc2654.txt- -2/Jensen
../data/rfc/rfc2654.txt- sn: 2/Jensen
../data/rfc/rfc2654.txt: title: 2/Accounting
../data/rfc/rfc2654.txt- -2/Manager
../data/rfc/rfc2654.txt- END Delete Block
../data/rfc/rfc2654.txt- BEGIN Update Block
../data/rfc/rfc2654.txt- BEGIN New
../data/rfc/rfc2654.txt- locality: 1/Jersey
--
../data/rfc/rfc2654.txt- -1/maker
../data/rfc/rfc2654.txt- locality: 1/New
../data/rfc/rfc2654.txt- -1/York
../data/rfc/rfc2654.txt- END Add Block
../data/rfc/rfc2654.txt- BEGIN Delete Block
../data/rfc/rfc2654.txt: dn: 1/cn=Bjorn Jensen, ou=Accounting, o=Ace Industry, c=US
../data/rfc/rfc2654.txt- END Delete Block
../data/rfc/rfc2654.txt- BEGIN Update Block
../data/rfc/rfc2654.txt- BEGIN New
../data/rfc/rfc2654.txt- dn: 1/cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US
../data/rfc/rfc2654.txt- -2/cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US
--
../data/rfc/rfc1104.txt-Braun [Page 8]
../data/rfc/rfc1104.txt-
../data/rfc/rfc1104.txt-RFC 1104 Models of Policy Based Routing June 1989
../data/rfc/rfc1104.txt-
../data/rfc/rfc1104.txt-
../data/rfc/rfc1104.txt:8. Accounting vs. Policy Based Routing
../data/rfc/rfc1104.txt-
../data/rfc/rfc1104.txt: Quite often Accounting and Policy Based Routing are discussed
../data/rfc/rfc1104.txt: together. While the application of both Accounting and Policy Based
../data/rfc/rfc1104.txt- Routing is to control access to scarce network resources, these are
../data/rfc/rfc1104.txt- separate (but related) issues.
../data/rfc/rfc1104.txt-
../data/rfc/rfc1104.txt: The chief difference between Accounting and Policy Based Routing is
../data/rfc/rfc1104.txt: that Accounting combines history information with policy information
../data/rfc/rfc1104.txt: to track network usage for various purposes. Accounting information
../data/rfc/rfc1104.txt- may in turn drive policy mechanisms (for instance, one could imagine
../data/rfc/rfc1104.txt- a policy limiting a certain organization to a fixed aggregate
../data/rfc/rfc1104.txt- percentage of dynamically shared bandwidth). Conversely, policy
../data/rfc/rfc1104.txt: information may affect accounting issues. Network accounting
../data/rfc/rfc1104.txt- typically involves route information (at any level from AD to end
../data/rfc/rfc1104.txt- system) and volume information (packet, octet counts).
../data/rfc/rfc1104.txt-
../data/rfc/rfc1104.txt: Accounting may be implemented in conjunction with any of the policy
../data/rfc/rfc1104.txt- models mentioned above. Similar to the microscopic versus
../data/rfc/rfc1104.txt: macroscopic policies, accounting may be classified into different
../data/rfc/rfc1104.txt: levels. One may collect accounting data at the AD level, network
../data/rfc/rfc1104.txt- level, host level, or even at the individual user level. However,
../data/rfc/rfc1104.txt: since accounting may be organized hierarchically, microscopic
../data/rfc/rfc1104.txt: accounting may be supported at the network or host level, while
../data/rfc/rfc1104.txt: macroscopic accounting may be supported at the network or AD level.
../data/rfc/rfc1104.txt- An example might be the amount of traffic passed at the interface
../data/rfc/rfc1104.txt- between the NSFNET and a mid-level network or between a mid-level
../data/rfc/rfc1104.txt- network and a campus. Furthermore, the NSFNET has facilities
../data/rfc/rfc1104.txt: implemented to allow for accounting of traffic trends from individual
../data/rfc/rfc1104.txt- network numbers as well as application-specific information.
../data/rfc/rfc1104.txt-
../data/rfc/rfc1104.txt: Full-blown accounting schemes suffer the same types of concerns
../data/rfc/rfc1104.txt- previously discussed, with the added complication of potentially
../data/rfc/rfc1104.txt- large amounts of additional data gathered that must be reliably
../data/rfc/rfc1104.txt- retrieved. As pointed out in [4], policy issues may impact the way
../data/rfc/rfc1104.txt: accounting data is collected (one administration billing for packets
../data/rfc/rfc1104.txt- that were then dropped in the network of another administration).
../data/rfc/rfc1104.txt: Microscopic accounting may not scale well in a large internet.
../data/rfc/rfc1104.txt-
../data/rfc/rfc1104.txt- Furthermore, from the standpoint of billing, it is not clear that the
../data/rfc/rfc1104.txt- services provided at the network layer map well to the sorts of
../data/rfc/rfc1104.txt- services that network consumers are willing to pay for. In the
../data/rfc/rfc1104.txt- telephone network (as well as public data networks), users pay for
--
../data/rfc/rfc1104.txt-Braun [Page 9]
../data/rfc/rfc1104.txt-
../data/rfc/rfc1104.txt-RFC 1104 Models of Policy Based Routing June 1989
../data/rfc/rfc1104.txt-
../data/rfc/rfc1104.txt-
../data/rfc/rfc1104.txt: Lightweight approaches to accounting can be used (with less impact)
../data/rfc/rfc1104.txt- when specific, limited goals are set. One suggested approach
../data/rfc/rfc1104.txt- involves monitoring traffic patterns. If a pattern of abuse (e.g.,
../data/rfc/rfc1104.txt: unauthorized use) develops, an accounting system could track this and
../data/rfc/rfc1104.txt- allow corrective action to be taken, by changing routing policy or
../data/rfc/rfc1104.txt- imposing access control (blocking hosts or nets). Note that this is
../data/rfc/rfc1104.txt- much less intrusive into the packet forwarding aspects of the
../data/rfc/rfc1104.txt- routers, but requires distribution of a policy database that the
../data/rfc/rfc1104.txt: accounting system can use to reduce the raw information. Because
../data/rfc/rfc1104.txt- this approach is statistical in nature, it may be slow to react.
../data/rfc/rfc1104.txt-
../data/rfc/rfc1104.txt-9. References
../data/rfc/rfc1104.txt-
../data/rfc/rfc1104.txt- [1] Rekhter, Y., "EGP and Policy Based Routing in the New NSFNET
--
../data/rfc/rfc7937.txt- 2.2.2. Logging Collection . . . . . . . . . . . . . . . . . 11
../data/rfc/rfc7937.txt- 2.2.3. Logging Filtering . . . . . . . . . . . . . . . . . . 11
../data/rfc/rfc7937.txt- 2.2.4. Logging Rectification and Post-Generation Aggregation 12
../data/rfc/rfc7937.txt- 2.2.5. Log-Consuming Applications . . . . . . . . . . . . . 13
../data/rfc/rfc7937.txt- 2.2.5.1. Maintenance and Debugging . . . . . . . . . . . . 13
../data/rfc/rfc7937.txt: 2.2.5.2. Accounting . . . . . . . . . . . . . . . . . . . 14
../data/rfc/rfc7937.txt- 2.2.5.3. Analytics and Reporting . . . . . . . . . . . . . 14
../data/rfc/rfc7937.txt- 2.2.5.4. Content Protection . . . . . . . . . . . . . . . 14
../data/rfc/rfc7937.txt- 2.2.5.5. Notions Common to Multiple Log-Consuming
../data/rfc/rfc7937.txt- Applications . . . . . . . . . . . . . . . . . . 15
../data/rfc/rfc7937.txt- 3. CDNI Logging File . . . . . . . . . . . . . . . . . . . . . . 17
--
../data/rfc/rfc7937.txt- NAT, where dynamic IP addresses are used and reused, etc.). However,
../data/rfc/rfc7937.txt- care SHOULD be taken so that the client identifiers exposed in other
../data/rfc/rfc7937.txt- fields of the CDNI Records cannot themselves be linked back to actual
../data/rfc/rfc7937.txt- users.
../data/rfc/rfc7937.txt-
../data/rfc/rfc7937.txt:2.2.5.2. Accounting
../data/rfc/rfc7937.txt-
../data/rfc/rfc7937.txt: Logging information is essential for accounting, to permit inter-CDN
../data/rfc/rfc7937.txt- billing and CSP billing by uCDNs. For instance, Logging information
../data/rfc/rfc7937.txt- provided by dCDNs enables the uCDN to compute the total amount of
../data/rfc/rfc7937.txt- traffic delivered by every dCDN for a particular Content Provider, as
../data/rfc/rfc7937.txt- well as the associated bandwidth usage (e.g., peak, 95th percentile),
../data/rfc/rfc7937.txt- and the maximum number of simultaneous sessions over a given period
--
../data/rfc/rfc913.txt-
../data/rfc/rfc913.txt- Tells the remote system you are done.
../data/rfc/rfc913.txt-
../data/rfc/rfc913.txt- The remote system replies:
../data/rfc/rfc913.txt-
../data/rfc/rfc913.txt: +(the message may be charge/accounting info)
../data/rfc/rfc913.txt-
../data/rfc/rfc913.txt- and then both systems close the connection.
../data/rfc/rfc913.txt-
../data/rfc/rfc913.txt-
../data/rfc/rfc913.txt-
--
../data/rfc/rfc985.txt- application level. It is expected that the network-level NSF
../data/rfc/rfc985.txt- gateway requirements summarized in this document will be
../data/rfc/rfc985.txt- incorporated in the requirements document for these
../data/rfc/rfc985.txt- application-level gateways.
../data/rfc/rfc985.txt-
../data/rfc/rfc985.txt: B.4. Access Control and Accounting
../data/rfc/rfc985.txt-
../data/rfc/rfc985.txt- There are no requirements for NSF gateways at this time to
../data/rfc/rfc985.txt: incorporate specific access-control and accounting mechanisms in
../data/rfc/rfc985.txt- the design; however, these important issues are currently under
../data/rfc/rfc985.txt- study and will be incorporated into a redraft of this document at
../data/rfc/rfc985.txt- an early date. Vendors are encouraged to plan for the early
../data/rfc/rfc985.txt- introduction of these mechanisms in their products. While at this
../data/rfc/rfc985.txt-
--
../data/rfc/rfc985.txt-
../data/rfc/rfc985.txt-RFC 985 May 1986
../data/rfc/rfc985.txt-Requirements for Internet Gateways -- DRAFT
../data/rfc/rfc985.txt-
../data/rfc/rfc985.txt-
../data/rfc/rfc985.txt: time no definitive common model for access control and accounting
../data/rfc/rfc985.txt- has emerged, it is possible to outline some general features such
../data/rfc/rfc985.txt- a model is likely to have, among them the following:
../data/rfc/rfc985.txt-
../data/rfc/rfc985.txt: 1. The primary access control and accounting executive
../data/rfc/rfc985.txt- mechanisms will be in the service hosts themselves, not the
../data/rfc/rfc985.txt- gateways, packet switches or workstations.
../data/rfc/rfc985.txt-
../data/rfc/rfc985.txt: 2. Agents acting on behalf of access control and accounting
../data/rfc/rfc985.txt- executive mechanisms may be necessary in the gateways,
../data/rfc/rfc985.txt- packet switches or workstations. These may be used to
../data/rfc/rfc985.txt- collect data, enforce password protection or mitigate
../data/rfc/rfc985.txt- resource priority and fairness. However, the architecture
../data/rfc/rfc985.txt- and protocols used by these agents may be a local matter
../data/rfc/rfc985.txt- and not possible to specify in advance.
../data/rfc/rfc985.txt-
../data/rfc/rfc985.txt- 3. NSF gateways may be required to incorporate access control
../data/rfc/rfc985.txt: and accounting mechanisms based on packet
../data/rfc/rfc985.txt- source/destination address, as well as other fields in the
../data/rfc/rfc985.txt- IP header, internal priority and fairness. However, it is
../data/rfc/rfc985.txt- extremely unlikely that these mechanisms would involve a
../data/rfc/rfc985.txt- user-level login to the gateway itself.
../data/rfc/rfc985.txt-
--
../data/rfc/rfc2527.txt- * Indemnification of CA and/or RA by relying parties;
../data/rfc/rfc2527.txt-
../data/rfc/rfc2527.txt- * Fiduciary relationships (or lack thereof) between the various
../data/rfc/rfc2527.txt- entities; and
../data/rfc/rfc2527.txt-
../data/rfc/rfc2527.txt: * Administrative processes (e.g., accounting, audit).
../data/rfc/rfc2527.txt-
../data/rfc/rfc2527.txt-4.2.4 Interpretation and Enforcement
../data/rfc/rfc2527.txt-
../data/rfc/rfc2527.txt- This subcomponent contains any applicable provisions regarding
../data/rfc/rfc2527.txt- interpretation and enforcement of the certificate policy or CPS,
--
../data/rfc/rfc2620.txt-Request for Comments: 2620 G. Zorn
../data/rfc/rfc2620.txt-Category: Informational Microsoft
../data/rfc/rfc2620.txt- June 1999
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt: RADIUS Accounting Client MIB
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-Status of this Memo
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt- This memo provides information for the Internet community. This memo
../data/rfc/rfc2620.txt- does not specify an Internet standard of any kind. Distribution of
--
../data/rfc/rfc2620.txt- Copyright (C) The Internet Society (1999). All Rights Reserved.
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-Abstract
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt- This memo defines a set of extensions which instrument RADIUS
../data/rfc/rfc2620.txt: accounting client functions. These extensions represent a portion of
../data/rfc/rfc2620.txt- the Management Information Base (MIB) for use with network management
../data/rfc/rfc2620.txt- protocols in the Internet community. Using these extensions IP-based
../data/rfc/rfc2620.txt: management stations can manage RADIUS accounting clients.
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-1. Introduction
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt- This memo defines a portion of the Management Information Base (MIB)
../data/rfc/rfc2620.txt- for use with network management protocols in the Internet community.
../data/rfc/rfc2620.txt- In particular, it describes managed objects used for managing RADIUS
../data/rfc/rfc2620.txt: accounting clients.
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt- Today a wide range of network devices, including routers and NASes,
../data/rfc/rfc2620.txt: act as RADIUS accounting clients in order to provide accounting
../data/rfc/rfc2620.txt: services. As a result, the effective management of RADIUS accounting
../data/rfc/rfc2620.txt- clients is of considerable importance.
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-2. The SNMP Management Framework
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt- The SNMP Management Framework presently consists of five major
--
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-Aboba & Zorn Informational [Page 1]
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt:RFC 2620 RADIUS Accounting Client MIB June 1999
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt- STD 15, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4].
../data/rfc/rfc2620.txt- The second version, called SMIv2, is described in STD 58, RFC
../data/rfc/rfc2620.txt- 2578 [5], RFC 2579 [6] and RFC 2580 [7].
--
../data/rfc/rfc2620.txt- readable information is not considered to change the semantics of the
../data/rfc/rfc2620.txt- MIB.
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-3. Overview
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt: The RADIUS accounting protocol, described in [16], distinguishes
../data/rfc/rfc2620.txt- between the client function and the server function. In RADIUS
../data/rfc/rfc2620.txt: accounting, clients send Accounting-Requests, and servers reply with
../data/rfc/rfc2620.txt: Accounting-Responses. Typically NAS devices implement the client
../data/rfc/rfc2620.txt- function, and thus would be expected to implement the RADIUS
../data/rfc/rfc2620.txt: accounting client MIB, while RADIUS accounting servers implement the
../data/rfc/rfc2620.txt- server function, and thus would be expected to implement the RADIUS
../data/rfc/rfc2620.txt: accounting server MIB.
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-Aboba & Zorn Informational [Page 2]
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt:RFC 2620 RADIUS Accounting Client MIB June 1999
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt: However, it is possible for a RADIUS accounting entity to perform
../data/rfc/rfc2620.txt- both client and server functions. For example, a RADIUS proxy may act
../data/rfc/rfc2620.txt: as a server to one or more RADIUS accounting clients, while
../data/rfc/rfc2620.txt: simultaneously acting as an accounting client to one or more
../data/rfc/rfc2620.txt: accounting servers. In such situations, it is expected that RADIUS
../data/rfc/rfc2620.txt- entities combining client and server functionality will support both
../data/rfc/rfc2620.txt- the client and server MIBs.
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-3.1. Selected objects
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt- This MIB module contains two scalars as well as a single table:
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt: (1) the RADIUS Accounting Server Table contains one row for
../data/rfc/rfc2620.txt- each RADIUS server that the client shares a secret with.
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt: Each entry in the RADIUS Accounting Server Table includes thirteen
../data/rfc/rfc2620.txt- columns presenting a view of the activity of the RADIUS client.
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-4. Definitions
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-RADIUS-ACC-CLIENT-MIB DEFINITIONS ::= BEGIN
--
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt- Phone: +1 425 936 6605
../data/rfc/rfc2620.txt- EMail: bernarda@microsoft.com"
../data/rfc/rfc2620.txt- DESCRIPTION
../data/rfc/rfc2620.txt- "The MIB module for entities implementing the client side of
../data/rfc/rfc2620.txt: the Remote Access Dialin User Service (RADIUS) accounting
../data/rfc/rfc2620.txt- protocol."
../data/rfc/rfc2620.txt- REVISION "9906110000Z" -- 11 Jun 1999
../data/rfc/rfc2620.txt- DESCRIPTION "Initial version as published in RFC 2620"
../data/rfc/rfc2620.txt: ::= { radiusAccounting 2 }
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-Aboba & Zorn Informational [Page 3]
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt:RFC 2620 RADIUS Accounting Client MIB June 1999
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-radiusMIB OBJECT-IDENTITY
../data/rfc/rfc2620.txt- STATUS current
../data/rfc/rfc2620.txt- DESCRIPTION
../data/rfc/rfc2620.txt- "The OID assigned to RADIUS MIB work by the IANA."
../data/rfc/rfc2620.txt- ::= { mib-2 67 }
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt:radiusAccounting OBJECT IDENTIFIER ::= {radiusMIB 2}
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-radiusAccClientMIBObjects OBJECT IDENTIFIER ::=
../data/rfc/rfc2620.txt- { radiusAccClientMIB 1 }
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-radiusAccClient OBJECT IDENTIFIER ::= { radiusAccClientMIBObjects 1 }
--
../data/rfc/rfc2620.txt-radiusAccClientInvalidServerAddresses OBJECT-TYPE
../data/rfc/rfc2620.txt- SYNTAX Counter32
../data/rfc/rfc2620.txt- MAX-ACCESS read-only
../data/rfc/rfc2620.txt- STATUS current
../data/rfc/rfc2620.txt- DESCRIPTION
../data/rfc/rfc2620.txt: "The number of RADIUS Accounting-Response packets
../data/rfc/rfc2620.txt- received from unknown addresses."
../data/rfc/rfc2620.txt- ::= { radiusAccClient 1 }
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-radiusAccClientIdentifier OBJECT-TYPE
../data/rfc/rfc2620.txt- SYNTAX SnmpAdminString
../data/rfc/rfc2620.txt- MAX-ACCESS read-only
../data/rfc/rfc2620.txt- STATUS current
../data/rfc/rfc2620.txt- DESCRIPTION
../data/rfc/rfc2620.txt: "The NAS-Identifier of the RADIUS accounting client. This
../data/rfc/rfc2620.txt- is not necessarily the same as sysName in MIB II."
../data/rfc/rfc2620.txt- ::= { radiusAccClient 2 }
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-radiusAccServerTable OBJECT-TYPE
../data/rfc/rfc2620.txt- SYNTAX SEQUENCE OF RadiusAccServerEntry
../data/rfc/rfc2620.txt- MAX-ACCESS not-accessible
../data/rfc/rfc2620.txt- STATUS current
../data/rfc/rfc2620.txt- DESCRIPTION
../data/rfc/rfc2620.txt: "The (conceptual) table listing the RADIUS accounting
../data/rfc/rfc2620.txt- servers with which the client shares a secret."
../data/rfc/rfc2620.txt- ::= { radiusAccClient 3 }
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-radiusAccServerEntry OBJECT-TYPE
../data/rfc/rfc2620.txt- SYNTAX RadiusAccServerEntry
../data/rfc/rfc2620.txt- MAX-ACCESS not-accessible
../data/rfc/rfc2620.txt- STATUS current
../data/rfc/rfc2620.txt- DESCRIPTION
../data/rfc/rfc2620.txt- "An entry (conceptual row) representing a RADIUS
../data/rfc/rfc2620.txt: accounting server with which the client shares a secret."
../data/rfc/rfc2620.txt- INDEX { radiusAccServerIndex }
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-Aboba & Zorn Informational [Page 4]
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt:RFC 2620 RADIUS Accounting Client MIB June 1999
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt- ::= { radiusAccServerTable 1 }
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-RadiusAccServerEntry ::= SEQUENCE {
--
../data/rfc/rfc2620.txt- SYNTAX Integer32 (1..2147483647)
../data/rfc/rfc2620.txt- MAX-ACCESS not-accessible
../data/rfc/rfc2620.txt- STATUS current
../data/rfc/rfc2620.txt- DESCRIPTION
../data/rfc/rfc2620.txt- "A number uniquely identifying each RADIUS
../data/rfc/rfc2620.txt: Accounting server with which this client
../data/rfc/rfc2620.txt- communicates."
../data/rfc/rfc2620.txt- ::= { radiusAccServerEntry 1 }
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-radiusAccServerAddress OBJECT-TYPE
../data/rfc/rfc2620.txt- SYNTAX IpAddress
../data/rfc/rfc2620.txt- MAX-ACCESS read-only
../data/rfc/rfc2620.txt- STATUS current
../data/rfc/rfc2620.txt- DESCRIPTION
../data/rfc/rfc2620.txt: "The IP address of the RADIUS accounting server
../data/rfc/rfc2620.txt- referred to in this table entry."
../data/rfc/rfc2620.txt- ::= { radiusAccServerEntry 2 }
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-radiusAccClientServerPortNumber OBJECT-TYPE
../data/rfc/rfc2620.txt- SYNTAX Integer32 (0..65535)
--
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-Aboba & Zorn Informational [Page 5]
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt:RFC 2620 RADIUS Accounting Client MIB June 1999
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt- MAX-ACCESS read-only
../data/rfc/rfc2620.txt- STATUS current
../data/rfc/rfc2620.txt- DESCRIPTION
../data/rfc/rfc2620.txt- "The time interval between the most recent
../data/rfc/rfc2620.txt: Accounting-Response and the Accounting-Request that
../data/rfc/rfc2620.txt: matched it from this RADIUS accounting server."
../data/rfc/rfc2620.txt- ::= { radiusAccServerEntry 4 }
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt--- Request/Response statistics
../data/rfc/rfc2620.txt---
../data/rfc/rfc2620.txt--- Requests = Responses + PendingRequests + ClientTimeouts
--
../data/rfc/rfc2620.txt-radiusAccClientRequests OBJECT-TYPE
../data/rfc/rfc2620.txt- SYNTAX Counter32
../data/rfc/rfc2620.txt- MAX-ACCESS read-only
../data/rfc/rfc2620.txt- STATUS current
../data/rfc/rfc2620.txt- DESCRIPTION
../data/rfc/rfc2620.txt: "The number of RADIUS Accounting-Request packets
../data/rfc/rfc2620.txt- sent. This does not include retransmissions."
../data/rfc/rfc2620.txt- ::= { radiusAccServerEntry 5 }
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-radiusAccClientRetransmissions OBJECT-TYPE
../data/rfc/rfc2620.txt- SYNTAX Counter32
../data/rfc/rfc2620.txt- MAX-ACCESS read-only
../data/rfc/rfc2620.txt- STATUS current
../data/rfc/rfc2620.txt- DESCRIPTION
../data/rfc/rfc2620.txt: "The number of RADIUS Accounting-Request packets
../data/rfc/rfc2620.txt: retransmitted to this RADIUS accounting server.
../data/rfc/rfc2620.txt- Retransmissions include retries where the
../data/rfc/rfc2620.txt- Identifier and Acct-Delay have been updated, as
../data/rfc/rfc2620.txt- well as those in which they remain the same."
../data/rfc/rfc2620.txt- ::= { radiusAccServerEntry 6 }
../data/rfc/rfc2620.txt-
--
../data/rfc/rfc2620.txt- SYNTAX Counter32
../data/rfc/rfc2620.txt- MAX-ACCESS read-only
../data/rfc/rfc2620.txt- STATUS current
../data/rfc/rfc2620.txt- DESCRIPTION
../data/rfc/rfc2620.txt- "The number of RADIUS packets received on the
../data/rfc/rfc2620.txt: accounting port from this server."
../data/rfc/rfc2620.txt- ::= { radiusAccServerEntry 7 }
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-radiusAccClientMalformedResponses OBJECT-TYPE
../data/rfc/rfc2620.txt- SYNTAX Counter32
../data/rfc/rfc2620.txt- MAX-ACCESS read-only
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-Aboba & Zorn Informational [Page 6]
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt:RFC 2620 RADIUS Accounting Client MIB June 1999
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt- STATUS current
../data/rfc/rfc2620.txt- DESCRIPTION
../data/rfc/rfc2620.txt: "The number of malformed RADIUS Accounting-Response
../data/rfc/rfc2620.txt- packets received from this server. Malformed packets
../data/rfc/rfc2620.txt- include packets with an invalid length. Bad
../data/rfc/rfc2620.txt- authenticators and unknown types are not included as
../data/rfc/rfc2620.txt: malformed accounting responses."
../data/rfc/rfc2620.txt- ::= { radiusAccServerEntry 8 }
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-radiusAccClientBadAuthenticators OBJECT-TYPE
../data/rfc/rfc2620.txt- SYNTAX Counter32
../data/rfc/rfc2620.txt- MAX-ACCESS read-only
../data/rfc/rfc2620.txt- STATUS current
../data/rfc/rfc2620.txt- DESCRIPTION
../data/rfc/rfc2620.txt: "The number of RADIUS Accounting-Response
../data/rfc/rfc2620.txt- packets which contained invalid authenticators
../data/rfc/rfc2620.txt- received from this server."
../data/rfc/rfc2620.txt- ::= { radiusAccServerEntry 9 }
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-radiusAccClientPendingRequests OBJECT-TYPE
../data/rfc/rfc2620.txt- SYNTAX Gauge32
../data/rfc/rfc2620.txt- MAX-ACCESS read-only
../data/rfc/rfc2620.txt- STATUS current
../data/rfc/rfc2620.txt- DESCRIPTION
../data/rfc/rfc2620.txt: "The number of RADIUS Accounting-Request packets
../data/rfc/rfc2620.txt- sent to this server that have not yet timed out or
../data/rfc/rfc2620.txt- received a response. This variable is incremented when an
../data/rfc/rfc2620.txt: Accounting-Request is sent and decremented due to
../data/rfc/rfc2620.txt: receipt of an Accounting-Response, a timeout or
../data/rfc/rfc2620.txt- a retransmission."
../data/rfc/rfc2620.txt- ::= { radiusAccServerEntry 10 }
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-radiusAccClientTimeouts OBJECT-TYPE
../data/rfc/rfc2620.txt- SYNTAX Counter32
../data/rfc/rfc2620.txt- MAX-ACCESS read-only
../data/rfc/rfc2620.txt- STATUS current
../data/rfc/rfc2620.txt- DESCRIPTION
../data/rfc/rfc2620.txt: "The number of accounting timeouts to this server.
../data/rfc/rfc2620.txt- After a timeout the client may retry to the same
../data/rfc/rfc2620.txt- server, send to a different server, or give up.
../data/rfc/rfc2620.txt- A retry to the same server is counted as a
../data/rfc/rfc2620.txt- retransmit as well as a timeout. A send to a different
../data/rfc/rfc2620.txt: server is counted as an Accounting-Request as well as
../data/rfc/rfc2620.txt- a timeout."
../data/rfc/rfc2620.txt- ::= { radiusAccServerEntry 11 }
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-radiusAccClientUnknownTypes OBJECT-TYPE
../data/rfc/rfc2620.txt- SYNTAX Counter32
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-Aboba & Zorn Informational [Page 7]
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt:RFC 2620 RADIUS Accounting Client MIB June 1999
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt- MAX-ACCESS read-only
../data/rfc/rfc2620.txt- STATUS current
../data/rfc/rfc2620.txt- DESCRIPTION
../data/rfc/rfc2620.txt- "The number of RADIUS packets of unknown type which
../data/rfc/rfc2620.txt: were received from this server on the accounting port."
../data/rfc/rfc2620.txt- ::= { radiusAccServerEntry 12 }
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-radiusAccClientPacketsDropped OBJECT-TYPE
../data/rfc/rfc2620.txt- SYNTAX Counter32
../data/rfc/rfc2620.txt- MAX-ACCESS read-only
../data/rfc/rfc2620.txt- STATUS current
../data/rfc/rfc2620.txt- DESCRIPTION
../data/rfc/rfc2620.txt- "The number of RADIUS packets which were received from
../data/rfc/rfc2620.txt: this server on the accounting port and dropped for some
../data/rfc/rfc2620.txt- other reason."
../data/rfc/rfc2620.txt- ::= { radiusAccServerEntry 13 }
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt--- conformance information
../data/rfc/rfc2620.txt-
--
../data/rfc/rfc2620.txt--- compliance statements
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-radiusAccClientMIBCompliance MODULE-COMPLIANCE
../data/rfc/rfc2620.txt- STATUS current
../data/rfc/rfc2620.txt- DESCRIPTION
../data/rfc/rfc2620.txt: "The compliance statement for accounting clients
../data/rfc/rfc2620.txt: implementing the RADIUS Accounting Client MIB."
../data/rfc/rfc2620.txt- MODULE -- this module
../data/rfc/rfc2620.txt- MANDATORY-GROUPS { radiusAccClientMIBGroup }
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt- ::= { radiusAccClientMIBCompliances 1 }
../data/rfc/rfc2620.txt-
--
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-Aboba & Zorn Informational [Page 8]
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt:RFC 2620 RADIUS Accounting Client MIB June 1999
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt- radiusAccClientRetransmissions,
../data/rfc/rfc2620.txt- radiusAccClientResponses,
../data/rfc/rfc2620.txt- radiusAccClientMalformedResponses,
--
../data/rfc/rfc2620.txt- radiusAccClientPacketsDropped
../data/rfc/rfc2620.txt- }
../data/rfc/rfc2620.txt- STATUS current
../data/rfc/rfc2620.txt- DESCRIPTION
../data/rfc/rfc2620.txt- "The basic collection of objects providing management of
../data/rfc/rfc2620.txt: RADIUS Accounting Clients."
../data/rfc/rfc2620.txt- ::= { radiusAccClientMIBGroups 1 }
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-END
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-5. References
--
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-Aboba & Zorn Informational [Page 9]
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt:RFC 2620 RADIUS Accounting Client MIB June 1999
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt- [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
../data/rfc/rfc2620.txt- "Introduction to Community-based SNMPv2", RFC 1901, January
../data/rfc/rfc2620.txt- 1996.
--
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt- [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access
../data/rfc/rfc2620.txt- Control Model for the Simple Network Management Protocol
../data/rfc/rfc2620.txt- (SNMP)", RFC 2575, April 1999.
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt: [16] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-6. Security Considerations
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt- There are no management objects defined in this MIB that have a MAX-
../data/rfc/rfc2620.txt- ACCESS clause of read-write and/or read-create. So, if this MIB is
--
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-Aboba & Zorn Informational [Page 10]
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt:RFC 2620 RADIUS Accounting Client MIB June 1999
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt- radiusAccServerAddress
../data/rfc/rfc2620.txt- This can be used to determine the address of the RADIUS
../data/rfc/rfc2620.txt: accounting server with which the client is communicating.
../data/rfc/rfc2620.txt- This information could be useful in mounting an attack on
../data/rfc/rfc2620.txt- the acounting server, which may contain sensitive financial
../data/rfc/rfc2620.txt- data.
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt- radiusAccClientServerPortNumber This can be used to determine the
../data/rfc/rfc2620.txt: port number on which the RADIUS accounting client is
../data/rfc/rfc2620.txt- sending. This information could be useful in impersonating
../data/rfc/rfc2620.txt- the client in order to send fraudulent data to the
../data/rfc/rfc2620.txt: accounting server.
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt- It is thus important to control even GET access to these objects and
../data/rfc/rfc2620.txt- possibly to even encrypt the values of these object when sending them
../data/rfc/rfc2620.txt- over the network via SNMP. Not all versions of SNMP provide features
../data/rfc/rfc2620.txt- for such a secure environment.
--
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-Aboba & Zorn Informational [Page 11]
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt:RFC 2620 RADIUS Accounting Client MIB June 1999
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-8. Authors' Addresses
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt- Bernard Aboba
--
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-Aboba & Zorn Informational [Page 12]
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt:RFC 2620 RADIUS Accounting Client MIB June 1999
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt-9. Full Copyright Statement
../data/rfc/rfc2620.txt-
../data/rfc/rfc2620.txt- Copyright (C) The Internet Society (1999). All Rights Reserved.
--
../data/rfc/rfc4031.txt- 7.2.4. Provisioning Network Access . . . . . . . . . . 39
../data/rfc/rfc4031.txt- 7.2.5. Provisioning Security Services. . . . . . . . . 40
../data/rfc/rfc4031.txt- 7.2.6. Provisioning VPN Resource Parameters. . . . . . 40
../data/rfc/rfc4031.txt- 7.2.7. Provisioning Value-Added Service Access . . . . 40
../data/rfc/rfc4031.txt- 7.2.8. Provisioning Hybrid VPN Services. . . . . . . . 41
../data/rfc/rfc4031.txt: 7.3. Accounting. . . . . . . . . . . . . . . . . . . . . . . 41
../data/rfc/rfc4031.txt- 7.4. Performance Management. . . . . . . . . . . . . . . . . 42
../data/rfc/rfc4031.txt- 7.4.1. Performance Monitoring. . . . . . . . . . . . . 42
../data/rfc/rfc4031.txt- 7.4.2. SLA and QoS Management Features . . . . . . . . 42
../data/rfc/rfc4031.txt- 7.5. Security Management . . . . . . . . . . . . . . . . . . 43
../data/rfc/rfc4031.txt- 7.5.1. Resource Access Control . . . . . . . . . . . . 43
--
../data/rfc/rfc4031.txt- O Manage the VPN networks deployed over these resources (network
../data/rfc/rfc4031.txt- management).
../data/rfc/rfc4031.txt-
../data/rfc/rfc4031.txt- o Manage the VPN service (service management).
../data/rfc/rfc4031.txt- o Manage the VPN business, mainly provisioning administrative and
../data/rfc/rfc4031.txt: accounting information related to the VPN service customers
../data/rfc/rfc4031.txt- (business management).
../data/rfc/rfc4031.txt-
../data/rfc/rfc4031.txt- Service management should include the TMN 'FCAPS' functionalities, as
../data/rfc/rfc4031.txt: follows: Fault, Configuration, Accounting, Provisioning, and
../data/rfc/rfc4031.txt- Security, as detailed in section 7.
../data/rfc/rfc4031.txt-
../data/rfc/rfc4031.txt-4.6. Interworking
../data/rfc/rfc4031.txt-
../data/rfc/rfc4031.txt- Interworking scenarios among different solutions providing L3VPN
--
../data/rfc/rfc4031.txt- languages) to access such systems is undesirable. Therefore, devices
../data/rfc/rfc4031.txt- SHOULD provide standards-based interfaces wherever feasible.
../data/rfc/rfc4031.txt-
../data/rfc/rfc4031.txt- The remainder of this section presents detailed SP management
../data/rfc/rfc4031.txt- requirements for a Network Management System (NMS) in the traditional
../data/rfc/rfc4031.txt: fault, configuration, accounting, performance, and security (FCAPS)
../data/rfc/rfc4031.txt- management categories. Much of this text was adapted from ITU-T
../data/rfc/rfc4031.txt- Y.1311.1.
../data/rfc/rfc4031.txt-
../data/rfc/rfc4031.txt-
../data/rfc/rfc4031.txt-
--
../data/rfc/rfc4031.txt-
../data/rfc/rfc4031.txt- Configuration of interworking or interconnection between L3VPN
../data/rfc/rfc4031.txt- solutions SHOULD be also supported. Ensuring that security and
../data/rfc/rfc4031.txt- end-to-end QoS issues are provided consistently SHOULD be addressed.
../data/rfc/rfc4031.txt-
../data/rfc/rfc4031.txt:7.3. Accounting
../data/rfc/rfc4031.txt-
../data/rfc/rfc4031.txt- Many service providers require collection of measurements regarding
../data/rfc/rfc4031.txt: resource usage for accounting purposes. The NMS MAY need to
../data/rfc/rfc4031.txt: correlate accounting information with performance and fault
../data/rfc/rfc4031.txt- management information to produce billing that takes into account SLA
../data/rfc/rfc4031.txt- provisions for periods of time when the SLS is not met.
../data/rfc/rfc4031.txt-
../data/rfc/rfc4031.txt: An L3VPN solution MUST describe how the following accounting
../data/rfc/rfc4031.txt- functions can be provided:
../data/rfc/rfc4031.txt-
../data/rfc/rfc4031.txt- - Measurements of resource utilization.
../data/rfc/rfc4031.txt: - collection of accounting information.
../data/rfc/rfc4031.txt- - storage and administration of measurements.
../data/rfc/rfc4031.txt-
../data/rfc/rfc4031.txt-
../data/rfc/rfc4031.txt-
../data/rfc/rfc4031.txt-
--
../data/rfc/rfc4031.txt- management service.
../data/rfc/rfc4031.txt-
../data/rfc/rfc4031.txt- If an SP supports a "Dynamic Bandwidth management" service, then the
../data/rfc/rfc4031.txt- dates, times, amounts, and interval required to perform requested
../data/rfc/rfc4031.txt- bandwidth allocation change(s) MUST be traceable for monitoring and
../data/rfc/rfc4031.txt: accounting purposes.
../data/rfc/rfc4031.txt-
../data/rfc/rfc4031.txt: Solutions should state compliance with accounting requirements, as
../data/rfc/rfc4031.txt- described in section 1.7 of RFC 2975 [RFC2975].
../data/rfc/rfc4031.txt-
../data/rfc/rfc4031.txt-7.4. Performance Management
../data/rfc/rfc4031.txt-
../data/rfc/rfc4031.txt- Performance management MUST support functions involved with
--
../data/rfc/rfc4031.txt- [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and
../data/rfc/rfc4031.txt- A. Malis, "A Framework for IP Based Virtual Private
../data/rfc/rfc4031.txt- Networks", RFC 2764, February 2000.
../data/rfc/rfc4031.txt-
../data/rfc/rfc4031.txt- [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction
../data/rfc/rfc4031.txt: to Accounting Management", RFC 2975, October 2000.
../data/rfc/rfc4031.txt-
../data/rfc/rfc4031.txt-
../data/rfc/rfc4031.txt-
../data/rfc/rfc4031.txt-
../data/rfc/rfc4031.txt-Carugi & McDysan Standards Track [Page 47]
--
../data/rfc/rfc5000.txt--------- The Early Session Disposition Type for the Session 3959*
../data/rfc/rfc5000.txt- Initiation Protocol (SIP)
../data/rfc/rfc5000.txt--------- Domain-Based Application Service Location Using SRV 3958*
../data/rfc/rfc5000.txt- RRs and the Dynamic Delegation Discovery Service
../data/rfc/rfc5000.txt- (DDDS)
../data/rfc/rfc5000.txt:-------- Authentication, Authorization, and Accounting (AAA) 3957*
../data/rfc/rfc5000.txt- Registration Keys for Mobile IPv4
../data/rfc/rfc5000.txt--------- Embedding the Rendezvous Point (RP) Address in an 3956*
../data/rfc/rfc5000.txt- IPv6 Multicast Address
../data/rfc/rfc5000.txt--------- Telephone Number Mapping (ENUM) Service Registration 3953*
../data/rfc/rfc5000.txt- for Presence Services
--
../data/rfc/rfc5000.txt--------- The Group Domain of Interpretation 3547
../data/rfc/rfc5000.txt--------- Enhanced Compressed RTP (CRTP) for Links with High 3545
../data/rfc/rfc5000.txt- Delay, Packet Loss and Reordering
../data/rfc/rfc5000.txt-IPCOM-PPP IP Header Compression over PPP 3544
../data/rfc/rfc5000.txt--------- Registration Revocation in Mobile IPv4 3543
../data/rfc/rfc5000.txt:-------- Authentication, Authorization and Accounting (AAA) 3539
../data/rfc/rfc5000.txt- Transport Profile
../data/rfc/rfc5000.txt--------- Wrapping a Hashed Message Authentication Code (HMAC) 3537
../data/rfc/rfc5000.txt- key with a Triple-Data Encryption Standard (DES) Key
../data/rfc/rfc5000.txt- or an Advanced Encryption Standard (AES) Key
../data/rfc/rfc5000.txt--------- The application/ogg Media Type 3534
--
../data/rfc/rfc5000.txt--------- Reserved IPv6 Subnet Anycast Addresses 2526
../data/rfc/rfc5000.txt-ATM-MIBMAN Definitions of Managed Objects for ATM Management 2515
../data/rfc/rfc5000.txt-ATM-TC-OID Definitions of Textual Conventions and 2514
../data/rfc/rfc5000.txt- OBJECT-IDENTITIES for ATM Management
../data/rfc/rfc5000.txt--------- Managed Objects for Controlling the Collection and 2513
../data/rfc/rfc5000.txt: Storage of Accounting Information for
../data/rfc/rfc5000.txt- Connection-Oriented Networks
../data/rfc/rfc5000.txt:-------- Accounting Information for ATM Networks 2512
../data/rfc/rfc5000.txt--------- Compressing IP/UDP/RTP Headers for Low-Speed Serial 2508
../data/rfc/rfc5000.txt- Links
../data/rfc/rfc5000.txt-
../data/rfc/rfc5000.txt-
../data/rfc/rfc5000.txt-
--
../data/rfc/rfc5000.txt- (MPLS) and Generalized MPLS (GMPLS) Protocols and
../data/rfc/rfc5000.txt- Procedures
../data/rfc/rfc5000.txt--------- IANA Considerations for OSPF 4940* 130
../data/rfc/rfc5000.txt--------- Symmetric RTP / RTP Control Protocol (RTCP) 4961* 131
../data/rfc/rfc5000.txt--------- Guidance for Authentication, Authorization, and 4962* 132
../data/rfc/rfc5000.txt: Accounting (AAA) Key Management
../data/rfc/rfc5000.txt--------- Specifying New Congestion Control Algorithms 5033* 133
../data/rfc/rfc5000.txt--------- Email Submission Operations: Access and 5068* 134
../data/rfc/rfc5000.txt- Accountability Requirements
../data/rfc/rfc5000.txt--------- IP Multicast Requirements for a Network Address 5135* 135
../data/rfc/rfc5000.txt- Translator (NAT) and a Network Address Port
--
../data/rfc/rfc5000.txt- Translator (NAPT)
../data/rfc/rfc5000.txt--------- Email Submission Operations: Access and 134 5068*
../data/rfc/rfc5000.txt- Accountability Requirements
../data/rfc/rfc5000.txt--------- Specifying New Congestion Control Algorithms 133 5033*
../data/rfc/rfc5000.txt--------- Guidance for Authentication, Authorization, and 132 4962*
../data/rfc/rfc5000.txt: Accounting (AAA) Key Management
../data/rfc/rfc5000.txt--------- Symmetric RTP / RTP Control Protocol (RTCP) 131 4961*
../data/rfc/rfc5000.txt--------- IANA Considerations for OSPF 130 4940*
../data/rfc/rfc5000.txt--------- Change Process for Multiprotocol Label Switching 129 4929*
../data/rfc/rfc5000.txt- (MPLS) and Generalized MPLS (GMPLS) Protocols
../data/rfc/rfc5000.txt- and Procedures
--
../data/rfc/rfc5000.txt- Control Protocol Transport Mapping
../data/rfc/rfc5000.txt--------- Select and Sort Extensions for the Service Location 3421
../data/rfc/rfc5000.txt- Protocol (SLP)
../data/rfc/rfc5000.txt--------- The Application Exchange (APEX) Presence Service 3343
../data/rfc/rfc5000.txt--------- Dual Stack Hosts Using "Bump-in-the-API" (BIA) 3338
../data/rfc/rfc5000.txt:-------- Policy-Based Accounting 3334
../data/rfc/rfc5000.txt--------- PGM Reliable Transport Protocol Specification 3208
../data/rfc/rfc5000.txt--------- Domain Security Services using S/MIME 3183
../data/rfc/rfc5000.txt-SMX Script MIB Extensibility Protocol Version 1.1 3179
../data/rfc/rfc5000.txt--------- ISO/IEC 9798-3 Authentication SASL Mechanism 3163
../data/rfc/rfc5000.txt--------- Electronic Signature Policies 3125
--
../data/rfc/rfc7925.txt-
../data/rfc/rfc7925.txt- Figure 2 shows the network access architecture with the IoT device
../data/rfc/rfc7925.txt- initiating the communication to an access point in the network using
../data/rfc/rfc7925.txt- the procedures defined for a specific physical layer. Since
../data/rfc/rfc7925.txt- credentials may be managed and stored centrally, in the
../data/rfc/rfc7925.txt: Authentication, Authorization, and Accounting (AAA) server, the
../data/rfc/rfc7925.txt- security protocol exchange may need to be relayed via the
../data/rfc/rfc7925.txt- Authenticator, i.e., functionality running on the access point to the
../data/rfc/rfc7925.txt- AAA server. The authentication and key exchange protocol itself is
../data/rfc/rfc7925.txt- encapsulated within a container, the Extensible Authentication
../data/rfc/rfc7925.txt- Protocol (EAP) [RFC3748], and messages are conveyed back and forth
--
../data/rfc/rfc7925.txt-
../data/rfc/rfc7925.txt-
../data/rfc/rfc7925.txt- +--------------+
../data/rfc/rfc7925.txt- |Authentication|
../data/rfc/rfc7925.txt- |Authorization |
../data/rfc/rfc7925.txt: |Accounting |
../data/rfc/rfc7925.txt- |Server |
../data/rfc/rfc7925.txt- |(EAP Server) |
../data/rfc/rfc7925.txt- | |
../data/rfc/rfc7925.txt- +-^----------^-+
../data/rfc/rfc7925.txt- * EAP o RADIUS/
--
../data/rfc/rfc5218.txt- to configure/manage, are cheaper to deploy.
../data/rfc/rfc5218.txt-
../data/rfc/rfc5218.txt- o Business dependencies: Protocols that don't require changes to a
../data/rfc/rfc5218.txt- business model (whether for implementers or deployers) are easier
../data/rfc/rfc5218.txt- to deploy than ones that do. There are costs associated with
../data/rfc/rfc5218.txt: changing billing and accounting systems and retraining of
../data/rfc/rfc5218.txt- associated personnel, and in addition, the assumptions on which
../data/rfc/rfc5218.txt- the previous business model was based may change. For example,
../data/rfc/rfc5218.txt- some time ago many service providers had business models built
../data/rfc/rfc5218.txt- around dial-up with an assumption that machines were not connected
../data/rfc/rfc5218.txt- all the time; protocols that desired always-on connectivity
--
../data/rfc/rfc4721.txt- agent to use a challenge/response mechanism to authenticate the
../data/rfc/rfc4721.txt- mobile node.
../data/rfc/rfc4721.txt-
../data/rfc/rfc4721.txt- Furthermore, this document updates RFC 3344 by including a new
../data/rfc/rfc4721.txt- authentication extension called the Mobile-Authentication,
../data/rfc/rfc4721.txt: Authorization, and Accounting (AAA) Authentication extension. This
../data/rfc/rfc4721.txt- new extension is provided so that a mobile node can supply
../data/rfc/rfc4721.txt- credentials for authorization, using commonly available AAA
../data/rfc/rfc4721.txt- infrastructure elements. This authorization-enabling extension MAY
../data/rfc/rfc4721.txt- co-exist in the same Registration Request with authentication
../data/rfc/rfc4721.txt- extensions defined for Mobile IP Registration by RFC 3344. This
--
../data/rfc/rfc4721.txt-
../data/rfc/rfc4721.txt- A mobile node MAY include the Mobile-AAA Authentication extension in
../data/rfc/rfc4721.txt- the Registration Request when the mobile node registers directly with
../data/rfc/rfc4721.txt- its home agent (using a co-located care-of address). In this case,
../data/rfc/rfc4721.txt- the mobile node uses an SPI value of CHAP_SPI (Section 8) in the
../data/rfc/rfc4721.txt: Mobile Node-Authentication, Authorization, and Accounting (MN-AAA)
../data/rfc/rfc4721.txt- Authentication extension and MUST NOT include the Mobile-Foreign
../data/rfc/rfc4721.txt- Challenge extension. Also, replay protection for the Registration
../data/rfc/rfc4721.txt- Request in this case is provided by the Identification field defined
../data/rfc/rfc4721.txt- by [RFC3344].
../data/rfc/rfc4721.txt-
--
../data/rfc/rfc5503.txt- information, and station information (e.g., coin-operated phone). In
../data/rfc/rfc5503.txt- addition, while translating the destination number, information such
../data/rfc/rfc5503.txt- as the local-number-portability office code is obtained and will be
../data/rfc/rfc5503.txt- needed by all other proxies handling this call.
../data/rfc/rfc5503.txt-
../data/rfc/rfc5503.txt: For Usage Accounting records, it is necessary to have an identifier
../data/rfc/rfc5503.txt- that can be associated with all the event records produced for the
../data/rfc/rfc5503.txt- call. The SIP Call-ID header field cannot be used as such an
../data/rfc/rfc5503.txt- identifier since it is selected by the originating user agent, and it
../data/rfc/rfc5503.txt- may not be unique among all past calls as well as current calls.
../data/rfc/rfc5503.txt- Further, since this identifier is to be used by the service provider,
--
../data/rfc/rfc5503.txt- servers, announcement servers, etc. Outside of the trust boundary
../data/rfc/rfc5503.txt- lie the customer premises equipment and various application and media
../data/rfc/rfc5503.txt- servers operated by third-party service providers.
../data/rfc/rfc5503.txt-
../data/rfc/rfc5503.txt- Certain subscriber-specific information, such as billing and
../data/rfc/rfc5503.txt: accounting information, stays within the trust boundary. Other
../data/rfc/rfc5503.txt- subscriber-specific information, such as endpoint identity, may be
../data/rfc/rfc5503.txt- presented to untrusted endpoints or may be withheld based on
../data/rfc/rfc5503.txt- subscriber profiles.
../data/rfc/rfc5503.txt-
../data/rfc/rfc5503.txt- The User Agent (UA) may be either within the trust boundary or
--
../data/rfc/rfc5503.txt- information based on the authenticated identity of the calling and
../data/rfc/rfc5503.txt- called parties. Since there is a trust relationship among proxies,
../data/rfc/rfc5503.txt- they can be relied upon to exchange trusted billing information
../data/rfc/rfc5503.txt- pertaining to the parties involved in a call.
../data/rfc/rfc5503.txt-
../data/rfc/rfc5503.txt: For Usage Accounting records, it is necessary to have an identifier
../data/rfc/rfc5503.txt- that can be associated with all the event records produced for the
../data/rfc/rfc5503.txt- call. The SIP Call-ID header field cannot be used as such an
../data/rfc/rfc5503.txt- identifier since it is selected by the originating user agent, and
../data/rfc/rfc5503.txt- may not be unique among all past calls as well as current calls.
../data/rfc/rfc5503.txt- Further, since this identifier is to be used by the service provider,
--
../data/rfc/rfc5503.txt- the ability of the originator to re-use this private-URL for multiple
../data/rfc/rfc5503.txt- calls.
../data/rfc/rfc5503.txt-
../data/rfc/rfc5503.txt- A UAC that includes a Refer-To header in a REFER request MUST include
../data/rfc/rfc5503.txt- a P-DCS-Billing-Info header in the Refer-To's URL. This P-DCS-
../data/rfc/rfc5503.txt: Billing-Info header MUST include the accounting information of the
../data/rfc/rfc5503.txt- initiator of the REFER.
../data/rfc/rfc5503.txt-
../data/rfc/rfc5503.txt-7.4. Procedures at an Untrusted User Agent Server (UAS)
../data/rfc/rfc5503.txt-
../data/rfc/rfc5503.txt- This header is never sent to an untrusted UAS, and is never sent by
--
../data/rfc/rfc5503.txt- provider policy provisioned in the UAS. If the UAS performed an LNP
../data/rfc/rfc5503.txt- query, it MUST include the Routing Number and Location Routing Number
../data/rfc/rfc5503.txt- returned by the query.
../data/rfc/rfc5503.txt-
../data/rfc/rfc5503.txt- The UAS MUST add a P-DCS-Billing-Info header to a 3xx-Redirect
../data/rfc/rfc5503.txt: response to an initial INVITE, giving the accounting information for
../data/rfc/rfc5503.txt- the call forwarder, for the call segment from the destination to the
../data/rfc/rfc5503.txt- forwarded-to destination.
../data/rfc/rfc5503.txt-
../data/rfc/rfc5503.txt-7.6. Procedures at Proxy
../data/rfc/rfc5503.txt-
--
../data/rfc/rfc5503.txt- removed.
../data/rfc/rfc5503.txt-
../data/rfc/rfc5503.txt- If the Request-URI contains a private-URL, and the decoded username
../data/rfc/rfc5503.txt- contains billing information, the originating proxy MUST generate a
../data/rfc/rfc5503.txt- P-DCS-Billing-Info header with that decrypted information.
../data/rfc/rfc5503.txt: Otherwise, the originating proxy MUST determine the accounting
../data/rfc/rfc5503.txt- information for the call originator and insert a P-DCS-Billing-Info
../data/rfc/rfc5503.txt- header including that information.
../data/rfc/rfc5503.txt-
../data/rfc/rfc5503.txt- If the response to the initial INVITE is a 3xx-Redirect, received
../data/rfc/rfc5503.txt- prior to a non-100 provisional response, the originating proxy
--
../data/rfc/rfc5503.txt- expiration time very shortly in the future, to limit the ability of
../data/rfc/rfc5503.txt- the originator to re-use this private-URL for multiple calls.
../data/rfc/rfc5503.txt-
../data/rfc/rfc5503.txt- An originating proxy that processes a REFER request from an untrusted
../data/rfc/rfc5503.txt- UA MUST include a P-DCS-Billing-Info header in the Refer-To's URL.
../data/rfc/rfc5503.txt: This P-DCS-Billing-Info header MUST include the accounting
../data/rfc/rfc5503.txt- information of the initiator.
../data/rfc/rfc5503.txt-
../data/rfc/rfc5503.txt-7.6.2. Procedures at Terminating Proxy
../data/rfc/rfc5503.txt-
../data/rfc/rfc5503.txt- The terminating proxy MUST NOT send the P-DCS-Billing-Info header to
--
../data/rfc/rfc5503.txt- proxy. If the terminating proxy performed an LNP query, it MUST
../data/rfc/rfc5503.txt- include the Routing Number and Location Routing Number returned by
../data/rfc/rfc5503.txt- the query.
../data/rfc/rfc5503.txt-
../data/rfc/rfc5503.txt- The terminating proxy MUST add P-DCS-Billing-Info headers to a 3xx-
../data/rfc/rfc5503.txt: Redirect response to an initial INVITE, giving the accounting
../data/rfc/rfc5503.txt- information for the call forwarder, for the call segment from the
../data/rfc/rfc5503.txt- destination to the forwarded-to destination.
../data/rfc/rfc5503.txt-
../data/rfc/rfc5503.txt- A proxy receiving a mid-call REFER request that includes a Refer-To
../data/rfc/rfc5503.txt- header generates a private-URL and places it in the Refer-To header
--
../data/rfc/rfc3169.txt-5.1. General protocol characteristics
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt- There are certain general characteristics that any AAA protocol used
../data/rfc/rfc3169.txt- by NAS's must meet. Note that the transport requirements for
../data/rfc/rfc3169.txt- authentication/authorization are not necessarily the same as those
../data/rfc/rfc3169.txt: for accounting/auditing. An AAA protocol suite MAY use the same
../data/rfc/rfc3169.txt- transport and protocol for both functions, but this is not strictly
../data/rfc/rfc3169.txt- required.
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt-5.1.1. Transport requirements
../data/rfc/rfc3169.txt-
--
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt-5.1.2.2. Minimum Set of Attributes
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt- At a minimum, the AAA protocol MUST support, or be easily extended to
../data/rfc/rfc3169.txt- support, the set of attributes supported by RADIUS [RADIUS] and
../data/rfc/rfc3169.txt: RADIUS Accounting [RADIUS-ACCOUNTING]. If the base AAA protocol does
../data/rfc/rfc3169.txt- not support this complete set of attributes, then an extension to
../data/rfc/rfc3169.txt- that protocol MUST be defined which supports this set.
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt-
--
../data/rfc/rfc3169.txt-RFC 3169 Criteria for Evaluating NAS Protocols September 2001
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt- MUST support selective encryption of attributes on an attribute-by-
../data/rfc/rfc3169.txt- attribute basis, even within the same message. This requirement
../data/rfc/rfc3169.txt: applies equally to Authentication, Authorization, and Accounting
../data/rfc/rfc3169.txt- data.
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt-5.2. Authentication and User Security Requirements
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt-5.2.1. Authentication protocol requirements
--
../data/rfc/rfc3169.txt- concurrent usage limits, port usage limits, and tunnel limits. This
../data/rfc/rfc3169.txt- capability should have error detection and synchronization features
../data/rfc/rfc3169.txt- that will recover state after network and system failures. This may
../data/rfc/rfc3169.txt- be accomplished by session information timeouts and explicit interim
../data/rfc/rfc3169.txt- status and disconnect messages. There should not be any dependencies
../data/rfc/rfc3169.txt: on the Accounting message stream, as per current practices.
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt-
--
../data/rfc/rfc3169.txt- authenticate compulsory tunnels, the AAA protocol MUST provide a
../data/rfc/rfc3169.txt- means of securing the credentials from end-to-end of the AAA
../data/rfc/rfc3169.txt- conversation. The AAA protocol MUST also provide protection against
../data/rfc/rfc3169.txt- replay attacks in this situation.
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt:5.4. Accounting and Auditing Requirements
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt:5.4.1. Accounting Protocol Requirements
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt-5.4.1.1. Guaranteed Delivery
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt: The accounting and auditing functions of the AAA protocol are used
../data/rfc/rfc3169.txt- for network planning, resource management, policy decisions, and
../data/rfc/rfc3169.txt- other functions that require accurate knowledge of the state of the
../data/rfc/rfc3169.txt- NAS. NAS operators need to be able to engineer their network usage
../data/rfc/rfc3169.txt- measurement systems to a predictable level of accuracy. Therefore,
../data/rfc/rfc3169.txt- an AAA protocol MUST provide a means of guaranteed delivery of
../data/rfc/rfc3169.txt: accounting information between the NAS and the AAA Server(s).
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt:5.4.1.2. Real Time Accounting
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt- NAS operators often require a real time view onto the status of
../data/rfc/rfc3169.txt- sessions served by a NAS. Therefore, the AAA protocol MUST support
../data/rfc/rfc3169.txt: real-time delivery of accounting and auditing information. In this
../data/rfc/rfc3169.txt: context, real time is defined as accounting information delivery
../data/rfc/rfc3169.txt- beginning within one second of the triggering event.
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt:5.4.1.3. Batch Accounting
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt: The AAA protocol SHOULD also support delivery of stored accounting
../data/rfc/rfc3169.txt- and auditing information in batches (non-real time).
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt-
--
../data/rfc/rfc3169.txt-Beadles & Mitton Informational [Page 11]
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt-RFC 3169 Criteria for Evaluating NAS Protocols September 2001
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt:5.4.1.4. Accounting Time Stamps
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt: There may be delays associated with the delivery of accounting
../data/rfc/rfc3169.txt- information. The NAS operator will desire to know the time an event
../data/rfc/rfc3169.txt- actually occurred, rather than simply the time when notification of
../data/rfc/rfc3169.txt- the event was received. Therefore, the AAA protocol MUST carry an
../data/rfc/rfc3169.txt: unambiguous time stamp associated with each accounting event. This
../data/rfc/rfc3169.txt- time stamp MUST be unambiguous with regard to time zone. Note that
../data/rfc/rfc3169.txt- this assumes that the NAS has access to a reliable time source.
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt:5.4.1.5. Accounting Events
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt: At a minimum, the AAA protocol MUST support delivery of accounting
../data/rfc/rfc3169.txt- information triggered by the following events:
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt- - Start of a user session
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt- - End of a user session
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt- - Expiration of a predetermined repeating time interval during a
../data/rfc/rfc3169.txt- user session. The AAA protocol MUST provide a means for the
../data/rfc/rfc3169.txt- AAA server to request that a NAS use a certain interval
../data/rfc/rfc3169.txt: accounting time.
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt- - Dynamic re-authorization during a user session (e.g., new
../data/rfc/rfc3169.txt- resources being delivered to the user)
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt- - Dynamic re-authentication during a user session
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt:5.4.1.6. On-Demand Accounting
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt- NAS operators need to maintain an accurate view onto the status of
../data/rfc/rfc3169.txt- sessions served by a NAS, even through failure of an AAA server.
../data/rfc/rfc3169.txt- Therefore, the AAA protocol MUST support a means of requesting
../data/rfc/rfc3169.txt: current session state and accounting from the NAS on demand.
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt:5.4.2. Accounting Attribute Requirements
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt- At a minimum, the AAA protocol MUST support delivery of the following
../data/rfc/rfc3169.txt: types of accounting/auditing data:
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt- - All parameters used to authenticate a session.
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt- - Details of the authorization profile that was applied to the
../data/rfc/rfc3169.txt- session.
--
../data/rfc/rfc3169.txt- the session.
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt- - Details of the access protocol used during the session (port
../data/rfc/rfc3169.txt- type, connect speeds, etc.)
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt:5.4.3. Accounting Protocol Security Requirements
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt-5.4.3.1. Integrity and Confidentiality
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt: Note that accounting and auditing data are operationally sensitive
../data/rfc/rfc3169.txt- information. The AAA protocol MUST provide a means to assure end-
../data/rfc/rfc3169.txt- to-end integrity of this data. The AAA protocol SHOULD provide a
../data/rfc/rfc3169.txt- means of assuring the end-to-end confidentiality of this data.
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt-5.4.3.2. Auditibility
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt: Network operators use accounting data for network planning, resource
../data/rfc/rfc3169.txt- management, and other business-critical functions that require
../data/rfc/rfc3169.txt- confidence in the correctness of this data. The AAA protocol SHOULD
../data/rfc/rfc3169.txt: provide a mechanism to ensure that the source of accounting data
../data/rfc/rfc3169.txt- cannot easily repudiate this data after transmission.
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt-6. Device Management Protocols
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt- This document does not specify any requirements for device management
--
../data/rfc/rfc3169.txt-Beadles & Mitton Informational [Page 15]
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt-RFC 3169 Criteria for Evaluating NAS Protocols September 2001
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt: [RADIUS-ACCOUNTING] Rigney, C., "RADIUS Accounting", RFC 2139,
../data/rfc/rfc3169.txt- April 1997.
../data/rfc/rfc3169.txt-
../data/rfc/rfc3169.txt- [ROAMING-REQUIREMENTS] Aboba, B. and G. Zorn, "Criteria for
../data/rfc/rfc3169.txt- Evaluating Roaming Protocols", RFC 2477,
../data/rfc/rfc3169.txt- January 1999.
--
../data/rfc/rfc1470.txt- interface.
../data/rfc/rfc1470.txt-
../data/rfc/rfc1470.txt- MECHANISM
../data/rfc/rfc1470.txt- SAS/CPE for Open Systems processes and reports data
../data/rfc/rfc1470.txt- from SNMP and other proprietary monitoring protocols,
../data/rfc/rfc1470.txt: as well as du and accounting.
../data/rfc/rfc1470.txt-
../data/rfc/rfc1470.txt- CAVEATS
../data/rfc/rfc1470.txt- The product is currently in alpha testing.
../data/rfc/rfc1470.txt-
../data/rfc/rfc1470.txt- BUGS
--
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- Description
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- The MS-CHAP-Domain Attribute indicates the Windows NT domain in
../data/rfc/rfc2548.txt- which the user was authenticated. It MAY be included in both
../data/rfc/rfc2548.txt: Access-Accept and Accounting-Request packets.
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- A summary of the MS-CHAP-Domain Attribute format is given below. The
../data/rfc/rfc2548.txt- fields are transmitted left to right.
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- 0 1 2 3
--
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- Description
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- The MS-RAS-Vendor Attribute is used to indicate the manufacturer
../data/rfc/rfc2548.txt- of the RADIUS client machine. It MAY be included in both Access-
../data/rfc/rfc2548.txt: Request and Accounting-Request packets.
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- A summary of the MS-RAS-Vendor Attribute format is given below. The
../data/rfc/rfc2548.txt- fields are transmitted left to right.
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- 0 1 2 3
--
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt-RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- sent in packets which do not contain an MS-RAS-Vendor Attribute.
../data/rfc/rfc2548.txt: It MAY be included in both Access-Request and Accounting-Request
../data/rfc/rfc2548.txt- packets.
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- A summary of the MS-RAS-Version Attribute format is given below. The
../data/rfc/rfc2548.txt- fields are transmitted left to right.
../data/rfc/rfc2548.txt-
--
../data/rfc/rfc2548.txt-2.7.3. MS-Filter
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- Description
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- The MS-Filter Attribute is used to transmit traffic filters. It
../data/rfc/rfc2548.txt: MAY be included in both Access-Accept and Accounting-Request
../data/rfc/rfc2548.txt- packets.
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- If multiple MS-Filter Attributes are contained within a packet,
../data/rfc/rfc2548.txt- they MUST be in order and they MUST be consecutive attributes in
../data/rfc/rfc2548.txt- the packet.
--
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- Description
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- The MS-Acct-Auth-Type Attribute is used to represent the method
../data/rfc/rfc2548.txt- used to authenticate the dial-up user. It MAY be included in
../data/rfc/rfc2548.txt: Accounting-Request packets.
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- A summary of the MS-Acct-Auth-Type Attribute format is given below.
../data/rfc/rfc2548.txt- The fields are transmitted left to right.
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- 0 1 2 3
--
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- Description
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- The MS-Acct-EAP-Type Attribute is used to represent the Extensible
../data/rfc/rfc2548.txt- Authentication Protocol (EAP) [15] type used to authenticate the
../data/rfc/rfc2548.txt: dial-up user. It MAY be included in Accounting-Request packets.
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- A summary of the MS-Acct-EAP-Type Attribute format is given below.
../data/rfc/rfc2548.txt- The fields are transmitted left to right.
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- 0 1 2 3
--
../data/rfc/rfc2548.txt- Description
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- The MS-Primary-DNS-Server Attribute is used to indicate the
../data/rfc/rfc2548.txt- address of the primary Domain Name Server (DNS) [16, 17] server to
../data/rfc/rfc2548.txt- be used by the PPP peer. It MAY be included in both Access-Accept
../data/rfc/rfc2548.txt: and Accounting-Request packets.
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- A summary of the MS-Primary-DNS-Server Attribute format is given
../data/rfc/rfc2548.txt- below. The fields are transmitted left to right.
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt-
--
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- Description
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- The MS-Secondary-DNS-Server Attribute is used to indicate the
../data/rfc/rfc2548.txt- address of the secondary DNS server to be used by the PPP peer.
../data/rfc/rfc2548.txt: It MAY be included in both Access-Accept and Accounting-Request
../data/rfc/rfc2548.txt- packets.
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- A summary of the MS-Secondary-DNS-Server Attribute format is given
../data/rfc/rfc2548.txt- below. The fields are transmitted left to right.
../data/rfc/rfc2548.txt-
--
../data/rfc/rfc2548.txt- Description
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- The MS-Primary-NBNS-Server Attribute is used to indicate the
../data/rfc/rfc2548.txt- address of the primary NetBIOS Name Server (NBNS) [18] server to
../data/rfc/rfc2548.txt- be used by the PPP peer. It MAY be included in both Access-Accept
../data/rfc/rfc2548.txt: and Accounting-Request packets.
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- A summary of the MS-Primary-MBNS-Server Attribute format is given
../data/rfc/rfc2548.txt- below. The fields are transmitted left to right.
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- 0 1 2 3
--
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- Description
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- The MS-Secondary-NBNS-Server Attribute is used to indicate the
../data/rfc/rfc2548.txt- address of the secondary DNS server to be used by the PPP peer.
../data/rfc/rfc2548.txt: It MAY be included in both Access-Accept and Accounting-Request
../data/rfc/rfc2548.txt- packets.
../data/rfc/rfc2548.txt-
../data/rfc/rfc2548.txt- A summary of the MS-Secondary-NBNS-Server Attribute format is given
../data/rfc/rfc2548.txt- below. The fields are transmitted left to right.
../data/rfc/rfc2548.txt-
--
../data/rfc/rfc5563.txt- more detail. The PPP/IPCP (IP Control Protocol) protocol involves a
../data/rfc/rfc5563.txt- PPP client in the mobile device and a Network Access Server (NAS) in
../data/rfc/rfc5563.txt- the AR. DHCP involves a DHCP client in the MN and a DHCP server in
../data/rfc/rfc5563.txt- either the AR or the HA. PMIPv4 involves a PMA in the AR and an HA
../data/rfc/rfc5563.txt- in the router on the home network. The Authentication,
../data/rfc/rfc5563.txt: Authorization, and Accounting (AAA) protocol involves a AAA client in
../data/rfc/rfc5563.txt- the AR and a AAA server in the network. The collocation of the
../data/rfc/rfc5563.txt- functional entities in the AR/HA enables parameters to be
../data/rfc/rfc5563.txt- shared/processed among the protocols.
../data/rfc/rfc5563.txt-
../data/rfc/rfc5563.txt- When the various network entities are not collocated, any sharing of
--
../data/rfc/rfc6610.txt-
../data/rfc/rfc6610.txt-4.4. Home Agent Discovery Using a Network Access Server
../data/rfc/rfc6610.txt-
../data/rfc/rfc6610.txt- [RFC5447] describes the complete procedure for home agent assignment
../data/rfc/rfc6610.txt- among the mobile node, NAS (Network Access Server), DHCP, and
../data/rfc/rfc6610.txt: Authentication, Authorization, and Accounting (AAA) entities for the
../data/rfc/rfc6610.txt- bootstrapping procedure in the integrated scenario.
../data/rfc/rfc6610.txt-
../data/rfc/rfc6610.txt- A NAS is assumed to be co-located with a DHCP relay agent or a DHCP
../data/rfc/rfc6610.txt- server in this solution. In a network where the NAS is not
../data/rfc/rfc6610.txt- co-located with a DHCP relay or a server, the server may not be
--
../data/rfc/rfc1716.txt-essential part of any router implementation. Although these functions
../data/rfc/rfc1716.txt-do not seem to relate directly to interoperability, they are essential
../data/rfc/rfc1716.txt-to the network manager who must make the router interoperate and must
../data/rfc/rfc1716.txt-track down problems when it doesn't. This chapter also includes some
../data/rfc/rfc1716.txt-discussion of router initialization and of facilities to assist network
../data/rfc/rfc1716.txt:managers in securing and accounting for their networks.
../data/rfc/rfc1716.txt-
../data/rfc/rfc1716.txt-10.1 Introduction
../data/rfc/rfc1716.txt-
../data/rfc/rfc1716.txt- The following kinds of activities are included under router O&M:
../data/rfc/rfc1716.txt-
--
../data/rfc/rfc1716.txt- Having the ability to track who made changes and when is
../data/rfc/rfc1716.txt- highly desirable, especially if your packets suddenly
../data/rfc/rfc1716.txt- start getting routed through Alaska on their way across
../data/rfc/rfc1716.txt- town.
../data/rfc/rfc1716.txt-
../data/rfc/rfc1716.txt: (2) Packet Accounting
../data/rfc/rfc1716.txt-
../data/rfc/rfc1716.txt- Vendors should strongly consider providing a system for
../data/rfc/rfc1716.txt- tracking traffic levels between pairs of hosts or networks.
../data/rfc/rfc1716.txt- A mechanism for limiting the collection of this information
../data/rfc/rfc1716.txt- to specific pairs of hosts or networks is also strongly
--
../data/rfc/rfc3145.txt- This document provides an extension to the Layer 2 Tunneling Protocol
../data/rfc/rfc3145.txt- ("L2TP"), a mechanism for tunneling Point-to-Point Protocol (PPP)
../data/rfc/rfc3145.txt- sessions. L2TP lacks a mechanism for a host to provide PPP-related
../data/rfc/rfc3145.txt- disconnect cause information to another host. This information,
../data/rfc/rfc3145.txt- provided by the extension described in this document, can be useful
../data/rfc/rfc3145.txt: for accounting and debugging purposes.
../data/rfc/rfc3145.txt-
../data/rfc/rfc3145.txt-1. Introduction
../data/rfc/rfc3145.txt-
../data/rfc/rfc3145.txt- L2TP [1] defines a general-purpose mechanism for tunneling PPP over
../data/rfc/rfc3145.txt- various media. By design, it insulates L2TP operation from the
--
../data/rfc/rfc7480.txt- send to a client. While no standard HTTP response code is forbidden
../data/rfc/rfc7480.txt- in usage, this section defines the minimal set of response codes in
../data/rfc/rfc7480.txt- common use by servers that a client will need to understand. While
../data/rfc/rfc7480.txt- some clients may be constructed with simple tooling that does not
../data/rfc/rfc7480.txt- account for all of these response codes, a more robust client
../data/rfc/rfc7480.txt: accounting for these codes will likely provide a better user
../data/rfc/rfc7480.txt- experience. It is expected that usage of response codes and types
../data/rfc/rfc7480.txt- for this application not defined here will be described in subsequent
../data/rfc/rfc7480.txt- documents.
../data/rfc/rfc7480.txt-
../data/rfc/rfc7480.txt-5.1. Positive Answers
--
../data/rfc/rfc3198.txt- and referenced. These non-policy terms will not be defined in this
../data/rfc/rfc3198.txt- document, and the reader is requested to go to the referenced ISD for
../data/rfc/rfc3198.txt- additional detail.
../data/rfc/rfc3198.txt-
../data/rfc/rfc3198.txt- $ AAA
../data/rfc/rfc3198.txt: See "Authentication, Authorization, Accounting".
../data/rfc/rfc3198.txt-
../data/rfc/rfc3198.txt- $ abstraction levels
../data/rfc/rfc3198.txt- See "policy abstraction".
../data/rfc/rfc3198.txt-
../data/rfc/rfc3198.txt- $ action
../data/rfc/rfc3198.txt- See "policy action".
../data/rfc/rfc3198.txt-
../data/rfc/rfc3198.txt: $ Authentication, Authorization, Accounting (AAA)
../data/rfc/rfc3198.txt- (A) AAA deals with control, authentication, authorization and
../data/rfc/rfc3198.txt: accounting of systems and environments based on policies set
../data/rfc/rfc3198.txt- by the administrators and users of the systems. The use of
../data/rfc/rfc3198.txt- policy may be implicit - as defined by RADIUS [RFC2138]. In
../data/rfc/rfc3198.txt- RADIUS, a network access server sends dial-user credentials to
../data/rfc/rfc3198.txt- an AAA server, and receives authentication that the user is
../data/rfc/rfc3198.txt-
--
../data/rfc/rfc5779.txt- Local Mobility Anchor Interaction with Diameter Server
../data/rfc/rfc5779.txt-
../data/rfc/rfc5779.txt-Abstract
../data/rfc/rfc5779.txt-
../data/rfc/rfc5779.txt- This specification defines Authentication, Authorization, and
../data/rfc/rfc5779.txt: Accounting (AAA) interactions between Proxy Mobile IPv6 entities
../data/rfc/rfc5779.txt- (both Mobile Access Gateway and Local Mobility Anchor) and a AAA
../data/rfc/rfc5779.txt- server within a Proxy Mobile IPv6 Domain. These AAA interactions are
../data/rfc/rfc5779.txt- primarily used to download and update mobile node specific policy
../data/rfc/rfc5779.txt- profile information between Proxy Mobile IPv6 entities and a remote
../data/rfc/rfc5779.txt- policy store.
--
../data/rfc/rfc5779.txt-
../data/rfc/rfc5779.txt-
../data/rfc/rfc5779.txt-1. Introduction
../data/rfc/rfc5779.txt-
../data/rfc/rfc5779.txt- This specification defines Authentication, Authorization, and
../data/rfc/rfc5779.txt: Accounting (AAA) interactions between a Mobile Access Gateway (MAG)
../data/rfc/rfc5779.txt- and a AAA server, and between a Local Mobility Anchor (LMA) and a AAA
../data/rfc/rfc5779.txt- server within a Proxy Mobile IPv6 (PMIPv6) Domain [RFC5213]. These
../data/rfc/rfc5779.txt- AAA interactions are primarily used to download and update mobile
../data/rfc/rfc5779.txt- node (MN) specific policy profile information between PMIPv6 entities
../data/rfc/rfc5779.txt- (a MAG and an LMA) and a remote policy store.
--
../data/rfc/rfc5779.txt-RFC 5779 Diameter Support for Proxy Mobile IPv6 February 2010
../data/rfc/rfc5779.txt-
../data/rfc/rfc5779.txt-
../data/rfc/rfc5779.txt- Home AAA (HAAA):
../data/rfc/rfc5779.txt-
../data/rfc/rfc5779.txt: An Authentication, Authorization, and Accounting (AAA) server
../data/rfc/rfc5779.txt- located in user's home network. A HAAA is essentially a Diameter
../data/rfc/rfc5779.txt- server.
../data/rfc/rfc5779.txt-
../data/rfc/rfc5779.txt-3. Solution Overview
../data/rfc/rfc5779.txt-
--
../data/rfc/rfc5779.txt-
../data/rfc/rfc5779.txt- The MAG-to-HAAA interactions are primarily used for bootstrapping
../data/rfc/rfc5779.txt- PMIPv6 mobility service session when an MN attaches and authenticates
../data/rfc/rfc5779.txt- to a PMIPv6 Domain. This includes the bootstrapping of PMIPv6
../data/rfc/rfc5779.txt- session-related information. The same interface may also be used for
../data/rfc/rfc5779.txt: accounting. The MAG acts as a Diameter client.
../data/rfc/rfc5779.txt-
../data/rfc/rfc5779.txt- Whenever the MAG sends a Diameter request message to the HAAA, the
../data/rfc/rfc5779.txt- User-Name AVP SHOULD contain the MN's identity unless the identity is
../data/rfc/rfc5779.txt- being suppressed for policy reasons -- for example, when identity
../data/rfc/rfc5779.txt- hiding is in effect. The MN identity, if available, MUST be in
--
../data/rfc/rfc5779.txt-
../data/rfc/rfc5779.txt- The LMA-to-HAAA interface may be used for multiple purposes. These
../data/rfc/rfc5779.txt- include the authorization of the incoming PBU, updating the LMA
../data/rfc/rfc5779.txt- address to the HAAA, delegating the assignment of the MN-HNP (home
../data/rfc/rfc5779.txt- network prefix) or the IPv4-HoA (home address) to the HAAA, and for
../data/rfc/rfc5779.txt: accounting and PMIPv6 session management. The primary purpose of
../data/rfc/rfc5779.txt- this interface is to update the HAAA with the LMA address information
../data/rfc/rfc5779.txt- in case of dynamically assigned LMA, and exchange the MN address
../data/rfc/rfc5779.txt- assignment information between the LMA and the HAAA.
../data/rfc/rfc5779.txt-
../data/rfc/rfc5779.txt- The LMA-to-HAAA interface description is intended for different types
--
../data/rfc/rfc5879.txt- Section 3 discusses failure modes of the heuristics. An attacker can
../data/rfc/rfc5879.txt- poison flows, tricking inspectors into ignoring legitimate ESP-NULL
../data/rfc/rfc5879.txt- flows, but that is no worse than injecting fuzz.
../data/rfc/rfc5879.txt-
../data/rfc/rfc5879.txt- Forcing the use of ESP-NULL everywhere inside the enterprise, so that
../data/rfc/rfc5879.txt: accounting, logging, network monitoring, and intrusion detection all
../data/rfc/rfc5879.txt- work, increases the risk of sending confidential information where
../data/rfc/rfc5879.txt- eavesdroppers can see it.
../data/rfc/rfc5879.txt-
../data/rfc/rfc5879.txt-10. References
../data/rfc/rfc5879.txt-
--
../data/rfc/rfc4377.txt-
../data/rfc/rfc4377.txt- The ability to detect denial of service (DoS) attacks against the
../data/rfc/rfc4377.txt- data or control planes MUST be part of any security management
../data/rfc/rfc4377.txt- related to MPLS OAM tools or techniques.
../data/rfc/rfc4377.txt-
../data/rfc/rfc4377.txt:4.11. Per-LSP Accounting Requirements
../data/rfc/rfc4377.txt-
../data/rfc/rfc4377.txt- In an MPLS network, service providers can measure traffic from an LSR
../data/rfc/rfc4377.txt- to the egress of the network using some MPLS related MIBs, for
../data/rfc/rfc4377.txt- example. This means that it is reasonable to know how much traffic
../data/rfc/rfc4377.txt- is traveling from location to location (i.e., a traffic matrix) by
../data/rfc/rfc4377.txt: analyzing the flow of traffic. Therefore, traffic accounting in an
../data/rfc/rfc4377.txt- MPLS network can be summarized as the following three items:
../data/rfc/rfc4377.txt-
../data/rfc/rfc4377.txt- (1) Collecting information to design network
../data/rfc/rfc4377.txt-
../data/rfc/rfc4377.txt- For the purpose of optimized network design, a service
--
../data/rfc/rfc4377.txt- (2) Providing a Service Level Specification
../data/rfc/rfc4377.txt-
../data/rfc/rfc4377.txt- Providers and their customers MAY need to verify high-level
../data/rfc/rfc4377.txt- service level specifications, either to continuously optimize
../data/rfc/rfc4377.txt- their networks, or to offer guaranteed bandwidth services.
../data/rfc/rfc4377.txt: Therefore, traffic accounting to monitor MPLS applications is
../data/rfc/rfc4377.txt- required.
../data/rfc/rfc4377.txt-
../data/rfc/rfc4377.txt- (3) Inter-AS environment
../data/rfc/rfc4377.txt-
../data/rfc/rfc4377.txt- Service providers that offer inter-AS services require
../data/rfc/rfc4377.txt: accounting of those services.
../data/rfc/rfc4377.txt-
../data/rfc/rfc4377.txt- These three motivations need to satisfy the following:
../data/rfc/rfc4377.txt-
../data/rfc/rfc4377.txt- - In (1) and (2), collection of information on a per-LSP
../data/rfc/rfc4377.txt- basis is a minimum level of granularity for collecting
../data/rfc/rfc4377.txt: accounting information at both of ingress and egress of an
../data/rfc/rfc4377.txt- LSP.
../data/rfc/rfc4377.txt-
../data/rfc/rfc4377.txt- - In (3), SP's ASBR carry out interconnection functions as an
../data/rfc/rfc4377.txt- intermediate LSR. Therefore, identifying a pair of ingress
../data/rfc/rfc4377.txt- and egress LSRs using each LSP is needed to determine the
--
../data/rfc/rfc4377.txt-RFC 4377 OAM Requirements for MPLS Networks February 2006
../data/rfc/rfc4377.txt-
../data/rfc/rfc4377.txt-
../data/rfc/rfc4377.txt-4.11.1. Requirements
../data/rfc/rfc4377.txt-
../data/rfc/rfc4377.txt: Accounting on a per-LSP basis encompasses the following set of
../data/rfc/rfc4377.txt- functions:
../data/rfc/rfc4377.txt-
../data/rfc/rfc4377.txt: (1) At an ingress LSR, accounting of traffic through LSPs that
../data/rfc/rfc4377.txt- begin at each egress in question.
../data/rfc/rfc4377.txt-
../data/rfc/rfc4377.txt: (2) At an intermediate LSR, accounting of traffic through LSPs for
../data/rfc/rfc4377.txt- each pair of ingress to egress.
../data/rfc/rfc4377.txt-
../data/rfc/rfc4377.txt: (3) At egress LSR, accounting of traffic through LSPs for each
../data/rfc/rfc4377.txt- ingress.
../data/rfc/rfc4377.txt-
../data/rfc/rfc4377.txt- (4) All LSRs containing LSPs that are being measured need to have
../data/rfc/rfc4377.txt- a common identifier to distinguish each LSP. The identifier
../data/rfc/rfc4377.txt- MUST be unique to each LSP, and its mapping to LSP SHOULD be
--
../data/rfc/rfc4377.txt- reading traffic counters for the label stack associated with the
../data/rfc/rfc4377.txt- LSP at any LSR along its path. However, in order to measure
../data/rfc/rfc4377.txt- merged LSPs, an LSR MUST have a means to distinguish the source of
../data/rfc/rfc4377.txt- each flow so as to disambiguate the statistics.
../data/rfc/rfc4377.txt-
../data/rfc/rfc4377.txt:4.11.2. Location of Accounting
../data/rfc/rfc4377.txt-
../data/rfc/rfc4377.txt- It is not realistic for LSRs to perform the described operations on
../data/rfc/rfc4377.txt- all LSPs that exist in a network. At a minimum, per-LSP based
../data/rfc/rfc4377.txt: accounting SHOULD be performed on the edges of the network -- at the
../data/rfc/rfc4377.txt- edges of both LSPs and the MPLS domain.
../data/rfc/rfc4377.txt-
../data/rfc/rfc4377.txt-5. Security Considerations
../data/rfc/rfc4377.txt-
../data/rfc/rfc4377.txt- Provisions to any of the network mechanisms designed to satisfy the
--
../data/rfc/rfc3929.txt- gravity of invoking these methods and partially to ensure that the
../data/rfc/rfc3929.txt- IETF community as a whole is alerted to and kept informed of the
../data/rfc/rfc3929.txt- process. Note that alternate procedures have been used in the past;
../data/rfc/rfc3929.txt- see [RFC3127] for a description of that used in the decision between
../data/rfc/rfc3929.txt- two competing candidate protocols for Authentication, Authorization,
../data/rfc/rfc3929.txt: and Accounting. By setting out these proposals, this document does
../data/rfc/rfc3929.txt- not intend to limit working group choice but intends to provide a set
../data/rfc/rfc3929.txt- of well-defined processes that obviate the need for reinvention in
../data/rfc/rfc3929.txt- most cases.
../data/rfc/rfc3929.txt-
../data/rfc/rfc3929.txt-
--
../data/rfc/rfc3929.txt-
../data/rfc/rfc3929.txt-8.2. Informative References
../data/rfc/rfc3929.txt-
../data/rfc/rfc3929.txt- [RFC3127] Mitton, D., StJohns, M., Barkley, S., Nelson, D., Patil,
../data/rfc/rfc3929.txt- B., Stevens, M., and B. Wolff, "Authentication,
../data/rfc/rfc3929.txt: Authorization, and Accounting: Protocol Evaluation", RFC
../data/rfc/rfc3929.txt- 3127, June 2001.
../data/rfc/rfc3929.txt-
../data/rfc/rfc3929.txt-
../data/rfc/rfc3929.txt-
../data/rfc/rfc3929.txt-Hardie Experimental [Page 9]
--
../data/rfc/rfc5851.txt- 3.2. Access-Loop Configuration . . . . . . . . . . . . . . . . 15
../data/rfc/rfc5851.txt- 3.3. Remote Connectivity Test . . . . . . . . . . . . . . . . . 16
../data/rfc/rfc5851.txt- 3.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 17
../data/rfc/rfc5851.txt- 3.4.1. Multicast Conditional Access . . . . . . . . . . . . . 18
../data/rfc/rfc5851.txt- 3.4.2. Multicast Admission Control . . . . . . . . . . . . . 21
../data/rfc/rfc5851.txt: 3.4.3. Multicast Accounting and Reporting . . . . . . . . . . 26
../data/rfc/rfc5851.txt- 3.4.4. Spontaneous Admission Response . . . . . . . . . . . . 27
../data/rfc/rfc5851.txt- 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 28
../data/rfc/rfc5851.txt- 4.1. ANCP Functional Requirements . . . . . . . . . . . . . . . 28
../data/rfc/rfc5851.txt- 4.2. ANCP Multicast Requirements . . . . . . . . . . . . . . . 29
../data/rfc/rfc5851.txt- 4.3. Protocol Design Requirements . . . . . . . . . . . . . . . 30
--
../data/rfc/rfc5851.txt- (or a specific circuit on an Access Port) using an addressing scheme.
../data/rfc/rfc5851.txt-
../data/rfc/rfc5851.txt- In deployments using an ATM aggregation network, the ATM PVC on an
../data/rfc/rfc5851.txt- access loop connects the subscriber to a NAS. Based on this
../data/rfc/rfc5851.txt- property, the NAS typically includes a NAS-Port-Id, NAS-Port, or
../data/rfc/rfc5851.txt: Calling-Station-Id attribute in RADIUS authentication and accounting
../data/rfc/rfc5851.txt- packets sent to the RADIUS server(s). Such attribute includes the
../data/rfc/rfc5851.txt- identification of the ATM VC for this subscriber, which allows in
../data/rfc/rfc5851.txt- turn identifying the access loop.
../data/rfc/rfc5851.txt-
../data/rfc/rfc5851.txt- In an Ethernet-based aggregation network, a new addressing scheme is
--
../data/rfc/rfc5851.txt- Control check for the new multicast flow and responds to the AN
../data/rfc/rfc5851.txt- indicating whether the join is to be denied or honored (and hence
../data/rfc/rfc5851.txt- replication performed by the AN). The NAS may locally keep track
../data/rfc/rfc5851.txt- of the portion of the access-loop net data rate that is available
../data/rfc/rfc5851.txt- for (unicast or multicast) video flows and perform video bandwidth
../data/rfc/rfc5851.txt: accounting for the access loop. Upon receiving an Admission
../data/rfc/rfc5851.txt- Request from the AN, the NAS can check available access-loop
../data/rfc/rfc5851.txt- bandwidth before admitting or denying the multicast flow. In the
../data/rfc/rfc5851.txt- process, the NAS may communicate with the policy server. For
../data/rfc/rfc5851.txt- unicast video services such as Video on Demand (VoD), the NAS may
../data/rfc/rfc5851.txt- also be queried (by a policy server or via on-path CAC signaling),
--
../data/rfc/rfc5851.txt- Some network deployments may combine the use of white list, black
../data/rfc/rfc5851.txt- list, and grey list. The implications of such a model to the overall
../data/rfc/rfc5851.txt- Multicast Admission Control model are not fully explored in this
../data/rfc/rfc5851.txt- document.
../data/rfc/rfc5851.txt-
../data/rfc/rfc5851.txt:3.4.3. Multicast Accounting and Reporting
../data/rfc/rfc5851.txt-
../data/rfc/rfc5851.txt: It may be desirable to perform time- and/or volume-based accounting
../data/rfc/rfc5851.txt- for certain multicast flows sent on particular Access Ports. In case
../data/rfc/rfc5851.txt- the AN is performing the traffic replication process, it knows when
../data/rfc/rfc5851.txt- replication of a multicast flow to a particular Access Port or user
../data/rfc/rfc5851.txt: start and stops. Multicast accounting can be addressed in two ways:
../data/rfc/rfc5851.txt-
../data/rfc/rfc5851.txt- o The AN keeps track of when replication for a given multicast flow
../data/rfc/rfc5851.txt- starts or ends on a specified Access Port, and generates time-
../data/rfc/rfc5851.txt: and/or volume-based accounting information per Access Port and per
../data/rfc/rfc5851.txt: multicast flow, before sending it to a central accounting system
../data/rfc/rfc5851.txt: for logging. Given that the AN communicates with the accounting
../data/rfc/rfc5851.txt- system directly, the approach doesn't require the use of ANCP. It
../data/rfc/rfc5851.txt- is therefore beyond the scope of this document;
../data/rfc/rfc5851.txt-
../data/rfc/rfc5851.txt- o The AN keeps track of when replication for a given multicast flow
../data/rfc/rfc5851.txt- starts or ends on a specified Access Port, and reports this
../data/rfc/rfc5851.txt- information to the NAS for further processing. In this case, ANCP
../data/rfc/rfc5851.txt- can be used to send the information from the AN to the NAS. This
../data/rfc/rfc5851.txt- will be discussed in the remainder of this document.
../data/rfc/rfc5851.txt-
../data/rfc/rfc5851.txt: The Access Node can send multicast accounting information to the NAS
../data/rfc/rfc5851.txt- using the Information Report message. A distinction can be made
../data/rfc/rfc5851.txt- between two cases:
../data/rfc/rfc5851.txt-
../data/rfc/rfc5851.txt: o Basic accounting information: the Access Node informs the NAS
../data/rfc/rfc5851.txt- whenever replication starts or ends for a given multicast flow on
../data/rfc/rfc5851.txt- a particular Access Port;
../data/rfc/rfc5851.txt-
../data/rfc/rfc5851.txt: o Detailed accounting information: the Access Node not only informs
../data/rfc/rfc5851.txt- the NAS when replication starts or ends, but also informs the NAS
../data/rfc/rfc5851.txt- about the multicast traffic volume replicated on the Access Port
../data/rfc/rfc5851.txt-
../data/rfc/rfc5851.txt-
../data/rfc/rfc5851.txt-
--
../data/rfc/rfc5851.txt- for that multicast flow. This is done by adding a byte count in
../data/rfc/rfc5851.txt- the Information Report message that is sent to the NAS when
../data/rfc/rfc5851.txt- replication ends.
../data/rfc/rfc5851.txt-
../data/rfc/rfc5851.txt- Upon receiving the Information Report messages, the NAS generates the
../data/rfc/rfc5851.txt: appropriate time- and/or volume-based accounting records per access
../data/rfc/rfc5851.txt: loop and per multicast flow to be sent to the accounting system.
../data/rfc/rfc5851.txt-
../data/rfc/rfc5851.txt: The NAS should inform the Access Node about the type of accounting
../data/rfc/rfc5851.txt- needed for a given multicast flow on a particular Access Port:
../data/rfc/rfc5851.txt-
../data/rfc/rfc5851.txt- o No reporting messages need to be sent to the NAS.
../data/rfc/rfc5851.txt-
../data/rfc/rfc5851.txt: o Basic accounting is required.
../data/rfc/rfc5851.txt-
../data/rfc/rfc5851.txt: o Detailed accounting is required.
../data/rfc/rfc5851.txt-
../data/rfc/rfc5851.txt- Note that in case of very fast channel changes, the amount of
../data/rfc/rfc5851.txt- Information Report messages to be sent to the NAS could become high.
../data/rfc/rfc5851.txt-
../data/rfc/rfc5851.txt- The ANCP requirements to support this use case are specified below in
--
../data/rfc/rfc5851.txt- R-18 The ANCP MUST allow the AN to send an Information Report
../data/rfc/rfc5851.txt- message to the NAS indicating the multicast traffic volume that
../data/rfc/rfc5851.txt- has been replicated on that port.
../data/rfc/rfc5851.txt-
../data/rfc/rfc5851.txt- R-19 The ANCP MUST allow the NAS to indicate to the AN whether or
../data/rfc/rfc5851.txt: not multicast accounting is needed for a multicast flow on a
../data/rfc/rfc5851.txt- particular Access Port.
../data/rfc/rfc5851.txt-
../data/rfc/rfc5851.txt: R-20 In case multicast accounting is needed for a multicast flow on
../data/rfc/rfc5851.txt- a particular Access Port, the ANCP MUST allow the NAS to
../data/rfc/rfc5851.txt: indicate to the AN whether or not additional volume accounting
../data/rfc/rfc5851.txt- information is required.
../data/rfc/rfc5851.txt-
../data/rfc/rfc5851.txt- R-21 The ANCP MUST allow the NAS to revoke a decision to replicate a
../data/rfc/rfc5851.txt- multicast flow to a particular Access Port, which had been
../data/rfc/rfc5851.txt- conveyed earlier to an AN.
--
../data/rfc/rfc5851.txt-
../data/rfc/rfc5851.txt- R-103 The NAS must support using ANCP to incrementally add, remove,
../data/rfc/rfc5851.txt- and modify individual entries in white, black, and grey lists.
../data/rfc/rfc5851.txt-
../data/rfc/rfc5851.txt- R-104 The NAS must support using ANCP to indicate to the AN whether
../data/rfc/rfc5851.txt: or not multicast accounting is needed for a multicast flow on
../data/rfc/rfc5851.txt- a particular Access Port.
../data/rfc/rfc5851.txt-
../data/rfc/rfc5851.txt: R-105 In case multicast accounting is needed for a multicast flow on
../data/rfc/rfc5851.txt- a particular Access Port, the NAS should support using ANCP to
../data/rfc/rfc5851.txt: indicate to the AN whether or not additional volume accounting
../data/rfc/rfc5851.txt- information is required.
../data/rfc/rfc5851.txt-
../data/rfc/rfc5851.txt- R-106 The NAS must support using ANCP to query the AN to obtain
../data/rfc/rfc5851.txt- information on what multicast flows are currently replicated
../data/rfc/rfc5851.txt- on a given Access Port.
--
../data/rfc/rfc8280.txt- Explanation: Certain technical choices may have unintended
../data/rfc/rfc8280.txt- consequences.
../data/rfc/rfc8280.txt-
../data/rfc/rfc8280.txt- Example: Lack of authenticity may lead to lack of integrity and
../data/rfc/rfc8280.txt- negative externalities; spam is an example. Lack of data that
../data/rfc/rfc8280.txt: could be used for billing and accounting can lead to so-called
../data/rfc/rfc8280.txt- "free" arrangements that obscure the actual costs and distribution
../data/rfc/rfc8280.txt- of the costs -- for example, (1) the barter arrangements that are
../data/rfc/rfc8280.txt- commonly used for Internet interconnection and (2) the commercial
../data/rfc/rfc8280.txt- exploitation of personal data for targeted advertising, which is
../data/rfc/rfc8280.txt- the most common funding model for the so-called "free" services
--
../data/rfc/rfc6937.txt- PRR does not change the risk profile for TCP.
../data/rfc/rfc6937.txt-
../data/rfc/rfc6937.txt- Implementers that change PRR from counting bytes to segments have to
../data/rfc/rfc6937.txt- be cautious about the effects of ACK splitting attacks [Savage99],
../data/rfc/rfc6937.txt- where the receiver acknowledges partial segments for the purpose of
../data/rfc/rfc6937.txt: confusing the sender's congestion accounting.
../data/rfc/rfc6937.txt-
../data/rfc/rfc6937.txt-9. References
../data/rfc/rfc6937.txt-
../data/rfc/rfc6937.txt-9.1. Normative References
../data/rfc/rfc6937.txt-
--
../data/rfc/rfc2093.txt- use of multicast communications protocols.
../data/rfc/rfc2093.txt-
../data/rfc/rfc2093.txt-1 Background
../data/rfc/rfc2093.txt-
../data/rfc/rfc2093.txt- Traditional key management distribution has mimicked the military
../data/rfc/rfc2093.txt: paper based key accounting system. Key was distributed, ordered, and
../data/rfc/rfc2093.txt- accounted physically leading to large lead times and expensive
../data/rfc/rfc2093.txt- operations.
../data/rfc/rfc2093.txt-
../data/rfc/rfc2093.txt- Cooperative key management algorithms exist that allow pairwise keys
../data/rfc/rfc2093.txt- to be generated between two equipment's. This gives the a quicker
--
../data/rfc/rfc3499.txt- Policy Service with Policy
../data/rfc/rfc3499.txt- Provisioning (COPS-PR)
../data/rfc/rfc3499.txt-
../data/rfc/rfc3499.txt-Common Open Policy Services (COPS) Protocol (RFC 2748), defines the
../data/rfc/rfc3499.txt-capability of reporting information to the Policy Decision Point (PDP).
../data/rfc/rfc3499.txt:The types of report information are success, failure and accounting of
../data/rfc/rfc3499.txt-an installed state. This document focuses on the COPS Report Type of
../data/rfc/rfc3499.txt:Accounting and the necessary framework for the monitoring and reporting
../data/rfc/rfc3499.txt-of usage feedback for an installed state. This memo provides
../data/rfc/rfc3499.txt-information for the Internet community.
../data/rfc/rfc3499.txt-
../data/rfc/rfc3499.txt-
../data/rfc/rfc3499.txt-3482 Foster Feb 2003 Number Portability in the
--
../data/rfc/rfc3499.txt-specific issues to be carefully evaluated before creating an UNSAF
../data/rfc/rfc3499.txt-proposal. This memo provides information for the Internet community.
../data/rfc/rfc3499.txt-
../data/rfc/rfc3499.txt-
../data/rfc/rfc3499.txt-3423 Zhang Nov 2002 XACCT's Common Reliable
../data/rfc/rfc3499.txt: Accounting for Network Element
../data/rfc/rfc3499.txt- (CRANE) Protocol Specification
../data/rfc/rfc3499.txt- Version 1.0
../data/rfc/rfc3499.txt-
../data/rfc/rfc3499.txt:This document defines the Common Reliable Accounting for Network Element
../data/rfc/rfc3499.txt-(CRANE) protocol that enables efficient and reliable delivery of any
../data/rfc/rfc3499.txt:data, mainly accounting data from Network Elements to any systems, such
../data/rfc/rfc3499.txt-as mediation systems and Business Support Systems (BSS)/ Operations
../data/rfc/rfc3499.txt-Support Systems (OSS). The protocol is developed to address the
../data/rfc/rfc3499.txt:critical needs for exporting high volume of accounting data from NE's
../data/rfc/rfc3499.txt-with efficient use of network, storage, and processing resources.
../data/rfc/rfc3499.txt-
../data/rfc/rfc3499.txt-This document specifies the architecture of the protocol and the message
../data/rfc/rfc3499.txt-format, which MUST be supported by all CRANE protocol implementations.
../data/rfc/rfc3499.txt-This memo provides information for the Internet community.
--
../data/rfc/rfc4877.txt- TSr}
../data/rfc/rfc4877.txt-
../data/rfc/rfc4877.txt- When EAP is used, the identity presented by the mobile node in the
../data/rfc/rfc4877.txt- IDi field may not be the actual identity of the mobile node. It
../data/rfc/rfc4877.txt- could be set to an identity that is used only for Authentication,
../data/rfc/rfc4877.txt: Authorization, and Accounting (AAA) routing purposes and selecting
../data/rfc/rfc4877.txt- the right EAP method. It is possible that the actual identity is
../data/rfc/rfc4877.txt-
../data/rfc/rfc4877.txt-
../data/rfc/rfc4877.txt-
../data/rfc/rfc4877.txt-Devarapalli & Dupont Standards Track [Page 21]
--
../data/rfc/rfc4687.txt- 4.6. Alarm Suppression, Aggregation, and Layer Coordination .....8
../data/rfc/rfc4687.txt- 4.7. Support for OAM Interworking for Fault Notification ........8
../data/rfc/rfc4687.txt- 4.8. Error Detection and Recovery ...............................9
../data/rfc/rfc4687.txt- 4.9. Standard Management Interfaces .............................9
../data/rfc/rfc4687.txt- 4.10. Detection of Denial of Service Attacks ...................10
../data/rfc/rfc4687.txt: 4.11. Per-LSP Accounting Requirements ..........................10
../data/rfc/rfc4687.txt- 5. Security Considerations ........................................10
../data/rfc/rfc4687.txt- 6. References .....................................................11
../data/rfc/rfc4687.txt- 6.1. Normative References ......................................11
../data/rfc/rfc4687.txt- 6.2. Informative References ....................................11
../data/rfc/rfc4687.txt- 7. Acknowledgements ...............................................12
--
../data/rfc/rfc4687.txt-
../data/rfc/rfc4687.txt- The ability to detect denial of service (DoS) attacks against the
../data/rfc/rfc4687.txt- data or control planes that signal P2MP LSPs MUST be part of any
../data/rfc/rfc4687.txt- security management related to MPLS OAM tools or techniques.
../data/rfc/rfc4687.txt-
../data/rfc/rfc4687.txt:4.11. Per-LSP Accounting Requirements
../data/rfc/rfc4687.txt-
../data/rfc/rfc4687.txt- In an MPLS network where P2MP LSPs are in use, Service Providers can
../data/rfc/rfc4687.txt- measure traffic from an LSR to the egress of the network using some
../data/rfc/rfc4687.txt- MPLS-related MIB modules (see section 4.9), for example. Other
../data/rfc/rfc4687.txt- interfaces MAY exist as well and enable the creation of traffic
--
../data/rfc/rfc4687.txt- pairing relationship between an ingress and a single egress.
../data/rfc/rfc4687.txt- Fundamental to understanding traffic flows within a network that
../data/rfc/rfc4687.txt- supports P2MP LSPs will be the knowledge of where the traffic is
../data/rfc/rfc4687.txt- branched for each LSP within the network, that is, where within the
../data/rfc/rfc4687.txt- network the branch nodes for the LSPs are located and what their
../data/rfc/rfc4687.txt: relationship is to links and other LSRs. Traffic flow and accounting
../data/rfc/rfc4687.txt- tools MUST take this fact into account.
../data/rfc/rfc4687.txt-
../data/rfc/rfc4687.txt-5. Security Considerations
../data/rfc/rfc4687.txt-
../data/rfc/rfc4687.txt- This document introduces no new security issues compared with
--
../data/rfc/rfc2124.txt- 1 - 14 (decimal) as specified in [1700]
../data/rfc/rfc2124.txt- 15 E.164 with NSAP format subaddress
../data/rfc/rfc2124.txt-
../data/rfc/rfc2124.txt-Flow ID IE
../data/rfc/rfc2124.txt-
../data/rfc/rfc2124.txt: In order to accumulate the flow accounting statistics across multiple
../data/rfc/rfc2124.txt- FAS's in case of a FAS failure a globally unique flow identifier
../data/rfc/rfc2124.txt- needs to be formed. To accomplish this the FAS assigns a prefix if
../data/rfc/rfc2124.txt- requested by the CCE. The CCE then assigns a CCE flow identifier
../data/rfc/rfc2124.txt- that it guaranties to be unique for the use of the FAS flow
../data/rfc/rfc2124.txt- identifier prefix for each flow admitted. If the CCE needs to reuse
--
../data/rfc/rfc926.txt-
../data/rfc/rfc926.txt-
../data/rfc/rfc926.txt- functions are tightly related to how one signals changes in Quality
../data/rfc/rfc926.txt- of Service.
../data/rfc/rfc926.txt-
../data/rfc/rfc926.txt: G. Accounting
../data/rfc/rfc926.txt-
../data/rfc/rfc926.txt- What entities, administrations, etc., are responsible for network
../data/rfc/rfc926.txt: accounting? How does this happen? What accounting information, if
../data/rfc/rfc926.txt- any, is required from the subnetworks in order to charge for network
../data/rfc/rfc926.txt- resources? Who is charged? To what degree is this to be standardized?
../data/rfc/rfc926.txt-
../data/rfc/rfc926.txt-
../data/rfc/rfc926.txt-
--
../data/rfc/rfc2064.txt- - METER REAERS, which collect traffic flow data from meters, and
../data/rfc/rfc2064.txt-
../data/rfc/rfc2064.txt- - MANAGERS, which oversee the operation of meters and meter readers.
../data/rfc/rfc2064.txt-
../data/rfc/rfc2064.txt- This memo defines the SNMP management information for a Traffic Flow
../data/rfc/rfc2064.txt: Meter (TFM). It documents the earlier work of the Internet Accounting
../data/rfc/rfc2064.txt- Working Group, and is intended to provide a starting point for the
../data/rfc/rfc2064.txt- Realtime Traffic Flow Measurement Working Group.
../data/rfc/rfc2064.txt-
../data/rfc/rfc2064.txt-3.1 Scope of Definitions, Textual Conventions
../data/rfc/rfc2064.txt-
--
../data/rfc/rfc2064.txt- SYNTAX Integer32
../data/rfc/rfc2064.txt- MAX-ACCESS read-create
../data/rfc/rfc2064.txt- STATUS current
../data/rfc/rfc2064.txt- DESCRIPTION
../data/rfc/rfc2064.txt- "Index to the array of rule sets. Specifies which set of
../data/rfc/rfc2064.txt: rules is currently being used for accounting by this manager.
../data/rfc/rfc2064.txt- When the manager sets this variable the meter will close its
../data/rfc/rfc2064.txt- current rule set and start using the new one. Flows created
../data/rfc/rfc2064.txt- by the old rule set remain in memory, orphaned until their
../data/rfc/rfc2064.txt- data has been read. Specifying rule set 0 (the empty set)
../data/rfc/rfc2064.txt- stops flow measurement by this manager."
--
../data/rfc/rfc2064.txt- SYNTAX AddressType
../data/rfc/rfc2064.txt- MAX-ACCESS read-only
../data/rfc/rfc2064.txt- STATUS current
../data/rfc/rfc2064.txt- DESCRIPTION
../data/rfc/rfc2064.txt- "Adjacent address type of the source for this flow. If
../data/rfc/rfc2064.txt: accounting is being performed at the network level the
../data/rfc/rfc2064.txt- adjacent address will probably be an 802 MAC address, and
../data/rfc/rfc2064.txt- the adjacent address type will indicate the medium type."
../data/rfc/rfc2064.txt- ::= { flowDataEntry 5 }
../data/rfc/rfc2064.txt-
../data/rfc/rfc2064.txt-flowDataSourceAdjacentAddress OBJECT-TYPE
--
../data/rfc/rfc2064.txt- STATUS current
../data/rfc/rfc2064.txt- DESCRIPTION
../data/rfc/rfc2064.txt- "Session ID for this flow. Such an ID might be allocated
../data/rfc/rfc2064.txt- by a network access server to distinguish a series of sessions
../data/rfc/rfc2064.txt- between the same pair of addresses, which would otherwise
../data/rfc/rfc2064.txt: appear to be parts of the same accounting flow."
../data/rfc/rfc2064.txt- ::= { flowDataEntry 35 }
../data/rfc/rfc2064.txt-
../data/rfc/rfc2064.txt-flowDataSourceClass OBJECT-TYPE
../data/rfc/rfc2064.txt- SYNTAX INTEGER (1..255)
../data/rfc/rfc2064.txt- MAX-ACCESS read-only
--
../data/rfc/rfc2064.txt- flowActiveFlows,
../data/rfc/rfc2064.txt- flowMaxFlows }
../data/rfc/rfc2064.txt- STATUS current
../data/rfc/rfc2064.txt- DESCRIPTION
../data/rfc/rfc2064.txt- "The control group defines objects which are used to control
../data/rfc/rfc2064.txt: an accounting meter."
../data/rfc/rfc2064.txt- ::= {flowMIBGroups 1 }
../data/rfc/rfc2064.txt-
../data/rfc/rfc2064.txt-flowDataTableGroup OBJECT-GROUP
../data/rfc/rfc2064.txt- OBJECTS {
../data/rfc/rfc2064.txt- flowDataIndex,
--
../data/rfc/rfc2064.txt-
../data/rfc/rfc2064.txt-
../data/rfc/rfc2064.txt-5 Acknowledgements
../data/rfc/rfc2064.txt-
../data/rfc/rfc2064.txt- This document was initially produced under the auspices of the IETF's
../data/rfc/rfc2064.txt: Accounting Working Group with assistance from SNMP and SAAG working
../data/rfc/rfc2064.txt- groups. Particular thanks are due to Jim Barnes, Sig Handelman and
../data/rfc/rfc2064.txt- Stephen Stibler for their support and their assistance with checking
../data/rfc/rfc2064.txt- the MIB.
../data/rfc/rfc2064.txt-
../data/rfc/rfc2064.txt-6 References
--
../data/rfc/rfc2064.txt-Brownlee Experimental [Page 37]
../data/rfc/rfc2064.txt-
../data/rfc/rfc2064.txt-RFC 2064 Meter MIB January 1997
../data/rfc/rfc2064.txt-
../data/rfc/rfc2064.txt-
../data/rfc/rfc2064.txt: [8] Mills, C., Hirsch, G. and G. Ruth, "Internet Accounting
../data/rfc/rfc2064.txt- Background," RFC 1272, Bolt Beranek and Newman Inc., Meridian
../data/rfc/rfc2064.txt- Technology Corporation, November 1991.
../data/rfc/rfc2064.txt-
../data/rfc/rfc2064.txt- [9] Brownlee, N., Mills, C., and G. Ruth, "Traffic Flow Measurement:
../data/rfc/rfc2064.txt- Architecture", RFC 2063, The University of Auckland, Bolt Beranek and
--
../data/rfc/rfc6973.txt- privacy protection goals as well.
../data/rfc/rfc6973.txt-
../data/rfc/rfc6973.txt- Some communications tasks require multiple protocol interactions with
../data/rfc/rfc6973.txt- different entities. For example, a request to an HTTP server may be
../data/rfc/rfc6973.txt- preceded by an interaction between the initiator and an
../data/rfc/rfc6973.txt: Authentication, Authorization, and Accounting (AAA) server for
../data/rfc/rfc6973.txt- network access and to a Domain Name System (DNS) server for name
../data/rfc/rfc6973.txt- resolution. In this case, the HTTP server is the recipient and the
../data/rfc/rfc6973.txt- other entities are enablers of the initiator-to-recipient
../data/rfc/rfc6973.txt- communication. Similarly, a single communication with the recipient
../data/rfc/rfc6973.txt- might generate further protocol interactions between either the
--
../data/rfc/rfc8501.txt- DDNS messages to the ISP's name server.
../data/rfc/rfc8501.txt-
../data/rfc/rfc8501.txt-2.3.6. Populate from RADIUS Server
../data/rfc/rfc8501.txt-
../data/rfc/rfc8501.txt- A user may receive an address or prefix from a RADIUS server
../data/rfc/rfc8501.txt: [RFC2865], the details of which may be recorded via RADIUS Accounting
../data/rfc/rfc8501.txt- data [RFC2866]. The ISP may populate the forward and reverse zones
../data/rfc/rfc8501.txt: from the accounting data if it contains enough information. This
../data/rfc/rfc8501.txt- solution allows the ISP to populate data concerning allocated
../data/rfc/rfc8501.txt- prefixes as per Section 2.2 (wildcards) and customer premise
../data/rfc/rfc8501.txt- equipment (CPE) endpoints. However, as with Section 2.3.5, it does
../data/rfc/rfc8501.txt- not allow the ISP to populate information concerning individual
../data/rfc/rfc8501.txt- hosts.
--
../data/rfc/rfc8501.txt- [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
../data/rfc/rfc8501.txt- "Remote Authentication Dial In User Service (RADIUS)",
../data/rfc/rfc8501.txt- RFC 2865, DOI 10.17487/RFC2865, June 2000,
../data/rfc/rfc8501.txt- <https://www.rfc-editor.org/info/rfc2865>.
../data/rfc/rfc8501.txt-
../data/rfc/rfc8501.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866,
../data/rfc/rfc8501.txt- DOI 10.17487/RFC2866, June 2000,
../data/rfc/rfc8501.txt- <https://www.rfc-editor.org/info/rfc2866>.
../data/rfc/rfc8501.txt-
../data/rfc/rfc8501.txt- [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
../data/rfc/rfc8501.txt- Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,
--
../data/rfc/rfc4746.txt-4.3.9. Fast Reconnect
../data/rfc/rfc4746.txt-
../data/rfc/rfc4746.txt- Although a specific fast reconnection option is not included,
../data/rfc/rfc4746.txt- execution of PAX_STD requires very little computation time and is
../data/rfc/rfc4746.txt- therefore bound primarily by the latency of the Authentication,
../data/rfc/rfc4746.txt: Authorization, and Accounting (AAA) server.
../data/rfc/rfc4746.txt-
../data/rfc/rfc4746.txt-4.3.10. Session Independence
../data/rfc/rfc4746.txt-
../data/rfc/rfc4746.txt- This protocol easily achieves backward secrecy through, among other
../data/rfc/rfc4746.txt- things, use of the PAX-KDF. Given a current session key, attackers
--
../data/rfc/rfc5113.txt- determine the roaming path that best matches the user's
../data/rfc/rfc5113.txt- preferences. This can lead to the user being charged more than
../data/rfc/rfc5113.txt- necessary, or not obtaining the desired services. For example,
../data/rfc/rfc5113.txt- the visited access realm could have both a direct relationship
../data/rfc/rfc5113.txt- with the home realm and an indirect relationship through a roaming
../data/rfc/rfc5113.txt: consortium. Current Authentication, Authorization, and Accounting
../data/rfc/rfc5113.txt- (AAA) protocols may not be able to route the access request to the
../data/rfc/rfc5113.txt- home AAA sever purely based on the realm within the Network Access
../data/rfc/rfc5113.txt- Identifier (NAI) [RFC4282]. In addition, payload packets can be
../data/rfc/rfc5113.txt- routed or tunneled differently, based on the roaming relationship
../data/rfc/rfc5113.txt- path. This may have an impact on the available services or their
--
../data/rfc/rfc5113.txt-Arkko, et al. Informational [Page 4]
../data/rfc/rfc5113.txt-
../data/rfc/rfc5113.txt-RFC 5113 Network Discovery and SP January 2008
../data/rfc/rfc5113.txt-
../data/rfc/rfc5113.txt-
../data/rfc/rfc5113.txt: Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc5113.txt-
../data/rfc/rfc5113.txt- AAA protocols with EAP support include Remote Authentication
../data/rfc/rfc5113.txt- Dial-In User Service (RADIUS) [RFC3579] and Diameter [RFC4072].
../data/rfc/rfc5113.txt-
../data/rfc/rfc5113.txt- Access Point (AP)
--
../data/rfc/rfc5113.txt-
../data/rfc/rfc5113.txt- Solutions to the AAA routing issues discussed in Section 2.3 need to
../data/rfc/rfc5113.txt- apply to a wide range of AAA messages, and should not restrict the
../data/rfc/rfc5113.txt- introduction of new AAA or access network functionality. For
../data/rfc/rfc5113.txt- example, AAA routing mechanisms should work for access requests and
../data/rfc/rfc5113.txt: responses as well as accounting requests and responses and server-
../data/rfc/rfc5113.txt- initiated messages. Solutions should not restrict the development of
../data/rfc/rfc5113.txt- new AAA attributes, access types, or performance optimizations (such
../data/rfc/rfc5113.txt- as fast handoff support).
../data/rfc/rfc5113.txt-
../data/rfc/rfc5113.txt-3.2. Backward Compatibility
--
../data/rfc/rfc167.txt-The current NCP Protocol says nothing about how hosts should assign
../data/rfc/rfc167.txt-socket numbers to process ports, except that the low-order bit is to
../data/rfc/rfc167.txt-specify socket gender (i.e., send or receive). Two recent proposals call
../data/rfc/rfc167.txt-for additional network-wide conventions on the 32-bit socket-number. The
../data/rfc/rfc167.txt-first proposal asks that a portion of the socket number be reserved for
../data/rfc/rfc167.txt:a network-unique user number for accounting and access control. The
../data/rfc/rfc167.txt-second proposal asks that the high-order 16 bits of the socket number be
../data/rfc/rfc167.txt-zero to assist smaller hosts in reducing the space required for socket
../data/rfc/rfc167.txt-number tables.
../data/rfc/rfc167.txt-
../data/rfc/rfc167.txt-It is recommended that both of these proposals be set aside. Because a
../data/rfc/rfc167.txt-large perturbation of the current NCP Protocol is required to provide
../data/rfc/rfc167.txt:adequate handles for accounting and access control, and because the
../data/rfc/rfc167.txt-socket number is already underpowered for its use, it is recommended
../data/rfc/rfc167.txt-that both proposals be set aside until serious consideration can be
../data/rfc/rfc167.txt-given to a major NCP Protocol overhaul.
../data/rfc/rfc167.txt-
../data/rfc/rfc167.txt-DISCUSSION
--
../data/rfc/rfc167.txt-The socket number, as it is used in the current NCP Protocol is a small
../data/rfc/rfc167.txt-number with a big function. It will probably be found that a
../data/rfc/rfc167.txt-substantially more powerful identification mechanism (e.g., a
../data/rfc/rfc167.txt-hierarchical naming scheme with arbitrarily long names) is required to
../data/rfc/rfc167.txt-satisfactorily manipulate process ports. Two features of such a
../data/rfc/rfc167.txt:mechanism will be (1) that it treats accounting and access control with
../data/rfc/rfc167.txt-the respect they deserve, and (2) that it is part of a simpler NCP
../data/rfc/rfc167.txt-Protocol more easily implemented under the existing size and complexity
../data/rfc/rfc167.txt-restrictions of smaller hosts.
../data/rfc/rfc167.txt-
../data/rfc/rfc167.txt-Socket numbers are process port identifiers used in establishing
--
../data/rfc/rfc1454.txt- topology. This obviously has signficance for addressing (whether
../data/rfc/rfc1454.txt- geographical or topological) and routing. There seems to be an
../data/rfc/rfc1454.txt- understanding of the problem, but so far no detailed specification of
../data/rfc/rfc1454.txt- a solution.
../data/rfc/rfc1454.txt-
../data/rfc/rfc1454.txt:4.3 Accounting
../data/rfc/rfc1454.txt-
../data/rfc/rfc1454.txt- The IESG selection criteria require only that proposals do not have
../data/rfc/rfc1454.txt- the effect of preventing the collection of information that may be of
../data/rfc/rfc1454.txt- interest for audit or billing purposes. Consequently, none of the
../data/rfc/rfc1454.txt: proposals consider potential accounting mechanisms.
../data/rfc/rfc1454.txt-
../data/rfc/rfc1454.txt-4.4 Security
../data/rfc/rfc1454.txt-
../data/rfc/rfc1454.txt- "Network Layer Security Issues are For Further Study". Or secret.
../data/rfc/rfc1454.txt-
--
../data/rfc/rfc8520.txt-
../data/rfc/rfc8520.txt-RFC 8520 Manufacturer Usage Descriptions March 2019
../data/rfc/rfc8520.txt-
../data/rfc/rfc8520.txt-
../data/rfc/rfc8520.txt- A MUD manager may be a component of an Authentication, Authorization,
../data/rfc/rfc8520.txt: and Accounting (AAA) system or a network management system.
../data/rfc/rfc8520.txt- Communication within those systems and from those systems to network
../data/rfc/rfc8520.txt- elements is beyond the scope of this memo.
../data/rfc/rfc8520.txt-
../data/rfc/rfc8520.txt-1.9. Order of Operations
../data/rfc/rfc8520.txt-
--
../data/rfc/rfc8520.txt- restart, similar to what it would do absent MUD manager
../data/rfc/rfc8520.txt- functionality. In the case where the DHCP server forwards
../data/rfc/rfc8520.txt- information to the MUD manager, the MUD manager will either make use
../data/rfc/rfc8520.txt- of redundant DHCP servers for information or clear state based on
../data/rfc/rfc8520.txt- other network information, such as monitoring port status on a switch
../data/rfc/rfc8520.txt: via SNMP, Radius accounting, or similar mechanisms.
../data/rfc/rfc8520.txt-
../data/rfc/rfc8520.txt-10.3. Relay Requirements
../data/rfc/rfc8520.txt-
../data/rfc/rfc8520.txt- There are no additional requirements for relays.
../data/rfc/rfc8520.txt-
--
../data/rfc/rfc2067.txt- kilobytes of user data consists of "n" full bursts and one short
../data/rfc/rfc2067.txt- burst equal in length to the number of bytes in the HIPPI, LLC, IP
../data/rfc/rfc2067.txt- and TCP headers. "Hold Time" is the minimum connection duration
../data/rfc/rfc2067.txt- needed to send the packets. "Burst Rate" is the effective transfer
../data/rfc/rfc2067.txt- rate for the duration of the connection, not counting connection
../data/rfc/rfc2067.txt: switching time. Throughput rates are in megabytes/second, accounting
../data/rfc/rfc2067.txt- for connection switching times of 10, 30, 60, 90, 120 and 150
../data/rfc/rfc2067.txt- microseconds. These calculations ignore any limit on the rate at
../data/rfc/rfc2067.txt- which a Source or Destination can process small packets; such limits
../data/rfc/rfc2067.txt- may further reduce the available throughput if small packets are
../data/rfc/rfc2067.txt- used.
--
../data/rfc/rfc2753.txt- rules or policy criteria are first applied before access is
../data/rfc/rfc2753.txt- granted. Examples of resources include the buffers in a router and
../data/rfc/rfc2753.txt- bandwidth on an interface.
../data/rfc/rfc2753.txt-
../data/rfc/rfc2753.txt- - Service Provider: Controls the network infrastructure and may be
../data/rfc/rfc2753.txt: responsible for the charging and accounting of services.
../data/rfc/rfc2753.txt-
../data/rfc/rfc2753.txt- - Soft State Model - Soft state is a form of the stateful model that
../data/rfc/rfc2753.txt- times out installed state at a PEP or PDP. It is an automatic way
../data/rfc/rfc2753.txt- to erase state in the presence of communication or network element
../data/rfc/rfc2753.txt- failures. For example, RSVP uses the soft state model for
--
../data/rfc/rfc2753.txt- including bi-lateral and multi-lateral service agreements and
../data/rfc/rfc2753.txt- policies based on the notion of relative priority. In general,
../data/rfc/rfc2753.txt- the determination and configuration of viable policies are the
../data/rfc/rfc2753.txt- responsibility of the service provider.
../data/rfc/rfc2753.txt-
../data/rfc/rfc2753.txt: - Provision for Monitoring and Accounting Information: The
../data/rfc/rfc2753.txt- mechanisms must include support for monitoring policy state,
../data/rfc/rfc2753.txt- resource usage, and provide access information. In particular,
../data/rfc/rfc2753.txt- mechanisms must be included to provide usage and access
../data/rfc/rfc2753.txt: information that may be used for accounting and billing purposes.
../data/rfc/rfc2753.txt-
../data/rfc/rfc2753.txt-
../data/rfc/rfc2753.txt-
../data/rfc/rfc2753.txt-
../data/rfc/rfc2753.txt-
--
../data/rfc/rfc2753.txt- may reside at a policy server. The PEP represents the component that
../data/rfc/rfc2753.txt- always runs on the policy aware node. It is the point at which policy
../data/rfc/rfc2753.txt- decisions are actually enforced. Policy decisions are made primarily
../data/rfc/rfc2753.txt- at the PDP. The PDP itself may make use of additional mechanisms and
../data/rfc/rfc2753.txt- protocols to achieve additional functionality such as user
../data/rfc/rfc2753.txt: authentication, accounting, policy information storage, etc. For
../data/rfc/rfc2753.txt- example, the PDP is likely to use an LDAP-based directory service for
../data/rfc/rfc2753.txt- storage and retrieval of policy information[6]. This document does
../data/rfc/rfc2753.txt- not include discussion of these additional mechanisms and protocols
../data/rfc/rfc2753.txt- and how they are used.
../data/rfc/rfc2753.txt-
--
../data/rfc/rfc2753.txt-| |
../data/rfc/rfc2753.txt-|________________|
../data/rfc/rfc2753.txt-
../data/rfc/rfc2753.txt- Figure 1: A simple configuration with the primary policy control
../data/rfc/rfc2753.txt- architecture components. PDP may use additional mechanisms and
../data/rfc/rfc2753.txt: protocols for the purpose of accounting, authentication, policy
../data/rfc/rfc2753.txt- storage, etc.
../data/rfc/rfc2753.txt-
../data/rfc/rfc2753.txt- The PDP might optionally contact other external servers, e.g., for
../data/rfc/rfc2753.txt: accessing configuration, user authentication, accounting and billing
../data/rfc/rfc2753.txt- databases. Protocols defined for network management (SNMP) or
../data/rfc/rfc2753.txt- directory access (LDAP) might be used for this communication. While
../data/rfc/rfc2753.txt- the specific type of access and the protocols used may vary among
../data/rfc/rfc2753.txt-
../data/rfc/rfc2753.txt-
--
../data/rfc/rfc2753.txt-
../data/rfc/rfc2753.txt- * PDP sends asynchronous notifications to PEP whenever necessary to
../data/rfc/rfc2753.txt- change earlier decisions, generate errors etc.
../data/rfc/rfc2753.txt-
../data/rfc/rfc2753.txt- * PDP exports the information useful for usage monitoring and
../data/rfc/rfc2753.txt: accounting purposes. An example of a useful mechanism for this
../data/rfc/rfc2753.txt- purpose is a MIB or a relational database. However, this document
../data/rfc/rfc2753.txt- does not specify any particular mechanism for this purpose and
../data/rfc/rfc2753.txt- discussion of such mechanisms is out of the scope of this
../data/rfc/rfc2753.txt- document.
../data/rfc/rfc2753.txt-
--
../data/rfc/rfc2753.txt-5.2. Bilateral agreements between service providers
../data/rfc/rfc2753.txt-
../data/rfc/rfc2753.txt- Until recently, usage agreements between service providers for
../data/rfc/rfc2753.txt- traffic crossing their boundaries have been quite simple. For
../data/rfc/rfc2753.txt- example, two ISPs might agree to accept all traffic from each other,
../data/rfc/rfc2753.txt: often without performing any accounting or billing for the "foreign"
../data/rfc/rfc2753.txt- traffic carried. However, with the availability of QoS mechanisms
../data/rfc/rfc2753.txt- based on Integrated and Differentiated Services, traffic
../data/rfc/rfc2753.txt- differentiation and quality of service guarantees are being phased
../data/rfc/rfc2753.txt- into the Internet. As ISPs start to sell their customers different
../data/rfc/rfc2753.txt- grades of service and can differentiate among different sources of
--
../data/rfc/rfc2753.txt- traffic (and reservations) transiting their networks. One additional
../data/rfc/rfc2753.txt- incentive in establishing such mechanisms is the potential asymmetry
../data/rfc/rfc2753.txt- in terms of the customer base that different providers will exhibit:
../data/rfc/rfc2753.txt- ISPs focused on servicing corporate traffic are likely to experience
../data/rfc/rfc2753.txt- much higher demand for reserved services than those that service the
../data/rfc/rfc2753.txt: consumer market. Lack of sophisticated accounting schemes for inter-
../data/rfc/rfc2753.txt- ISP traffic could lead to inefficient allocation of costs among
../data/rfc/rfc2753.txt- different service providers.
../data/rfc/rfc2753.txt-
../data/rfc/rfc2753.txt- Bilateral agreements could fall into two broad categories; local or
../data/rfc/rfc2753.txt- global. Due to the complexity of the problem, it is expected that
../data/rfc/rfc2753.txt- initially only the former will be deployed. In these, providers which
../data/rfc/rfc2753.txt- manage a network cloud or administrative domain contract with their
../data/rfc/rfc2753.txt- closest point of contact (neighbor) to establish ground rules and
../data/rfc/rfc2753.txt: arrangements for access control and accounting. These contracts are
../data/rfc/rfc2753.txt- mostly local and do not rely on global agreements; consequently, a
../data/rfc/rfc2753.txt- policy node maintains information about its neighboring nodes only.
../data/rfc/rfc2753.txt- Referring to Figure 4, this model implies that provider AD-1 has
../data/rfc/rfc2753.txt- established arrangements with AD-2, but not with AD-3, for usage of
../data/rfc/rfc2753.txt- each other's network. Provider AD-2, in turn, has in place agreements
--
../data/rfc/rfc2753.txt-
../data/rfc/rfc2753.txt- * Reliability: The sensitivity of policy control information
../data/rfc/rfc2753.txt- necessitates reliable operation. Undetected loss of policy queries
../data/rfc/rfc2753.txt- or responses may lead to inconsistent network control operation
../data/rfc/rfc2753.txt- and are clearly unacceptable for actions such as billing and
../data/rfc/rfc2753.txt: accounting. One option for providing reliability is the re-use of
../data/rfc/rfc2753.txt- the TCP as the transport protocol.
../data/rfc/rfc2753.txt-
../data/rfc/rfc2753.txt- * Small delays: The timing requirements of policy decisions related
../data/rfc/rfc2753.txt- to QoS signaling protocols are expected to be quite strict. The
../data/rfc/rfc2753.txt- PEP to PDP protocol should add small amount of delay to the
--
../data/rfc/rfc3272.txt-
../data/rfc/rfc3272.txt- (5) A set of administrative control parameters which may be
../data/rfc/rfc3272.txt- manipulated through a Configuration Management (CM) system.
../data/rfc/rfc3272.txt- The CM system itself may include a configuration control
../data/rfc/rfc3272.txt- subsystem, a configuration repository, a configuration
../data/rfc/rfc3272.txt: accounting subsystem, and a configuration auditing
../data/rfc/rfc3272.txt- subsystem.
../data/rfc/rfc3272.txt-
../data/rfc/rfc3272.txt- (6) A set of guidelines for network performance evaluation,
../data/rfc/rfc3272.txt- performance optimization, and performance improvement.
../data/rfc/rfc3272.txt-
--
../data/rfc/rfc3272.txt-
../data/rfc/rfc3272.txt-5.6 Open-Loop Versus Closed-Loop
../data/rfc/rfc3272.txt-
../data/rfc/rfc3272.txt- Open-loop traffic engineering control is where control action does
../data/rfc/rfc3272.txt- not use feedback information from the current network state. The
../data/rfc/rfc3272.txt: control action may use its own local information for accounting
../data/rfc/rfc3272.txt- purposes, however.
../data/rfc/rfc3272.txt-
../data/rfc/rfc3272.txt- Closed-loop traffic engineering control is where control action
../data/rfc/rfc3272.txt- utilizes feedback information from the network state. The feedback
../data/rfc/rfc3272.txt- information may be in the form of historical information or current
--
../data/rfc/rfc1675.txt- authentication. This may not be bad; in fact, it is probably good.
../data/rfc/rfc1675.txt- But it is vital that a more secure cryptographic authentication
../data/rfc/rfc1675.txt- protocol be defined and deployed before any substantial cutover to
../data/rfc/rfc1675.txt- source routing, if SIPP is adopted.
../data/rfc/rfc1675.txt-
../data/rfc/rfc1675.txt:Accounting
../data/rfc/rfc1675.txt-
../data/rfc/rfc1675.txt- An significant part of the world wishes to do usage-sensitive
../data/rfc/rfc1675.txt: accounting. This may be for billing, or it may simply be to
../data/rfc/rfc1675.txt- accomodate quality-of-service requests. Either way, definitive
../data/rfc/rfc1675.txt- knowledge of the relevant address fields is needed. To accomodate
../data/rfc/rfc1675.txt- this, IPng should have a non-intrusive packet authentication
../data/rfc/rfc1675.txt- mechanism. By "non-intrusive", I mean that it should (a) present
../data/rfc/rfc1675.txt- little or no load to intermediate hops that do not need to do
--
../data/rfc/rfc504.txt- different resources be standardized? How can resources which may
../data/rfc/rfc504.txt- move from Host to Host or may be available on several Hosts be
../data/rfc/rfc504.txt- dynamically located and selected for use? The need for
../data/rfc/rfc504.txt- (desirability of) a "broadcast ICP".
../data/rfc/rfc504.txt-
../data/rfc/rfc504.txt:4. Problems of accounting for resource utilization.
../data/rfc/rfc504.txt: Some form of network wide accounting would be a great convenience.
../data/rfc/rfc504.txt- For example, it would be nice if a user could use the same account
../data/rfc/rfc504.txt- at many (all?) sites. What are the problems (if any) preventing
../data/rfc/rfc504.txt- this?
../data/rfc/rfc504.txt-
../data/rfc/rfc504.txt-
--
../data/rfc/rfc504.txt- automated resource sharing experiments?
../data/rfc/rfc504.txt-- Under what conditions would your site be willing or able to
../data/rfc/rfc504.txt- participate in such experiments?
../data/rfc/rfc504.txt-- What administrative and/or technical considerations would prevent your
../data/rfc/rfc504.txt- site from entering into a network wide resource sharing agreement?
../data/rfc/rfc504.txt:- If you employ accounting Procedures that require cost recovery, how,
../data/rfc/rfc504.txt- if at all, should they be modified to work in a network resource
../data/rfc/rfc504.txt- sharing environment?
../data/rfc/rfc504.txt-
../data/rfc/rfc504.txt-
../data/rfc/rfc504.txt-Reading List:
--
../data/rfc/rfc431.txt-file. The user name and account number specified remain in
../data/rfc/rfc431.txt-effect until another LGI command is issued, a LGO command is
../data/rfc/rfc431.txt-issued, or the connection is close.
../data/rfc/rfc431.txt-
../data/rfc/rfc431.txt- At present, the use of SMFS is not billed, and therefore
../data/rfc/rfc431.txt:use of the accounting command is optional. It is requested,
../data/rfc/rfc431.txt-however, that users and user processes begin to use this command
../data/rfc/rfc431.txt-as soon as possible, since we would like to collect statistics on
../data/rfc/rfc431.txt-SMFS utilization before implementing billing. Therefore, at
../data/rfc/rfc431.txt-present the user name can be any name that identifies the user,
../data/rfc/rfc431.txt-and the account number is completely arbitrary.
--
../data/rfc/rfc431.txt-consist of characters chosen from the same character set as
../data/rfc/rfc431.txt-filenames.
../data/rfc/rfc431.txt-
../data/rfc/rfc431.txt- Logout (LGO)
../data/rfc/rfc431.txt- The logout command terminates the association between the
../data/rfc/rfc431.txt:user and the accounting information specified in the last LGI
../data/rfc/rfc431.txt-command issued, if any; it does not cause SMFS to close the
../data/rfc/rfc431.txt-connection. The user should then issue another LGI command
../data/rfc/rfc431.txt-before attempting any operation referencing a file. It is not
../data/rfc/rfc431.txt-necessary to issue a LGO command before issuing another LGI
../data/rfc/rfc431.txt-command, or before closing the connection.
--
../data/rfc/rfc7599.txt- using standard IPv6 means applicable in the network where the CE is
../data/rfc/rfc7599.txt- located.
../data/rfc/rfc7599.txt-
../data/rfc/rfc7599.txt- The MAP provisioning parameters, and hence the IPv4 service itself,
../data/rfc/rfc7599.txt- are tied to the End-user IPv6 prefix; thus, the MAP service is also
../data/rfc/rfc7599.txt: tied to this in terms of authorization, accounting, etc.
../data/rfc/rfc7599.txt-
../data/rfc/rfc7599.txt- A single MAP CE MAY be connected to more than one MAP domain, just as
../data/rfc/rfc7599.txt- any router may have more than one IPv4-enabled service-provider-
../data/rfc/rfc7599.txt- facing interface and more than one set of associated addresses
../data/rfc/rfc7599.txt- assigned by DHCPv6. Each domain within which a given CE operates
--
../data/rfc/rfc2139.txt-Request for Comments: 2139 Livingston
../data/rfc/rfc2139.txt-Obsoletes: 2059 April 1997
../data/rfc/rfc2139.txt-Category: Informational
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: RADIUS Accounting
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Status of this Memo
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- This memo provides information for the Internet community. This memo
../data/rfc/rfc2139.txt- does not specify an Internet standard of any kind. Distribution of
../data/rfc/rfc2139.txt- this memo is unlimited.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Abstract
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: This document describes a protocol for carrying accounting
../data/rfc/rfc2139.txt: information between a Network Access Server and a shared Accounting
../data/rfc/rfc2139.txt- Server.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Implementation Note
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: This memo documents the RADIUS Accounting protocol. There has been
../data/rfc/rfc2139.txt- some confusion in the assignment of port numbers for this protocol.
../data/rfc/rfc2139.txt: The early deployment of RADIUS Accounting was done using the
../data/rfc/rfc2139.txt- erroneously chosen port number 1646, which conflicts with the "sa-
../data/rfc/rfc2139.txt- msg-port" service. The officially assigned port number for RADIUS
../data/rfc/rfc2139.txt: Accounting is 1813.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Table of Contents
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- 1. Introduction .......................................... 2
../data/rfc/rfc2139.txt- 1.1 Specification of Requirements ................... 3
../data/rfc/rfc2139.txt- 1.2 Terminology ..................................... 3
../data/rfc/rfc2139.txt- 2. Operation ............................................. 4
../data/rfc/rfc2139.txt- 3. Packet Format ......................................... 5
../data/rfc/rfc2139.txt- 4. Packet Types .......................................... 7
../data/rfc/rfc2139.txt: 4.1 Accounting-Request .............................. 7
../data/rfc/rfc2139.txt: 4.2 Accounting-Response ............................. 8
../data/rfc/rfc2139.txt- 5. Attributes ............................................ 10
../data/rfc/rfc2139.txt- 5.1 Acct-Status-Type ................................ 11
../data/rfc/rfc2139.txt- 5.2 Acct-Delay-Time ................................. 12
../data/rfc/rfc2139.txt- 5.3 Acct-Input-Octets ............................... 13
../data/rfc/rfc2139.txt- 5.4 Acct-Output-Octets .............................. 14
--
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Rigney Informational [Page 1]
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt:RFC 2139 RADIUS Accounting April 1997
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- 5.9 Acct-Output-Packets ............................. 17
../data/rfc/rfc2139.txt- 5.10 Acct-Terminate-Cause ............................ 18
../data/rfc/rfc2139.txt- 5.11 Acct-Multi-Session-Id ........................... 20
--
../data/rfc/rfc2139.txt-1. Introduction
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Managing dispersed serial line and modem pools for large numbers of
../data/rfc/rfc2139.txt- users can create the need for significant administrative support.
../data/rfc/rfc2139.txt- Since modem pools are by definition a link to the outside world, they
../data/rfc/rfc2139.txt: require careful attention to security, authorization and accounting.
../data/rfc/rfc2139.txt- This can be best achieved by managing a single "database" of users,
../data/rfc/rfc2139.txt- which allows for authentication (verifying user name and password) as
../data/rfc/rfc2139.txt- well as configuration information detailing the type of service to
../data/rfc/rfc2139.txt- deliver to the user (for example, SLIP, PPP, telnet, rlogin).
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- The RADIUS (Remote Authentication Dial In User Service) document [4]
../data/rfc/rfc2139.txt- specifies the RADIUS protocol used for Authentication and
../data/rfc/rfc2139.txt- Authorization. This memo extends the use of the RADIUS protocol to
../data/rfc/rfc2139.txt: cover delivery of accounting information from the Network Access
../data/rfc/rfc2139.txt: Server (NAS) to a RADIUS accounting server.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: Key features of RADIUS Accounting are:
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Client/Server Model
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- A Network Access Server (NAS) operates as a client of the
../data/rfc/rfc2139.txt: RADIUS accounting server. The client is responsible for
../data/rfc/rfc2139.txt: passing user accounting information to a designated RADIUS
../data/rfc/rfc2139.txt: accounting server.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: The RADIUS accounting server is responsible for receiving the
../data/rfc/rfc2139.txt: accounting request and returning a response to the client
../data/rfc/rfc2139.txt- indicating that it has successfully received the request.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: The RADIUS accounting server can act as a proxy client to other
../data/rfc/rfc2139.txt: kinds of accounting servers.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Rigney Informational [Page 2]
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt:RFC 2139 RADIUS Accounting April 1997
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Network Security
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: Transactions between the client and RADIUS accounting server
../data/rfc/rfc2139.txt- are authenticated through the use of a shared secret, which is
../data/rfc/rfc2139.txt- never sent over the network.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Extensible Protocol
../data/rfc/rfc2139.txt-
--
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Rigney Informational [Page 3]
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt:RFC 2139 RADIUS Accounting April 1997
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- session Each service provided by the NAS to a dial-in user
../data/rfc/rfc2139.txt- constitutes a session, with the beginning of the session
../data/rfc/rfc2139.txt- defined as the point where service is first provided and
../data/rfc/rfc2139.txt- the end of the session defined as the point where service
../data/rfc/rfc2139.txt- is ended. A user may have multiple sessions in parallel or
../data/rfc/rfc2139.txt- series if the NAS supports that, with each session
../data/rfc/rfc2139.txt: generating a separate start and stop accounting record with
../data/rfc/rfc2139.txt- its own Acct-Session-Id.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- silently discard
../data/rfc/rfc2139.txt- This means the implementation discards the packet without
../data/rfc/rfc2139.txt- further processing. The implementation SHOULD provide the
--
../data/rfc/rfc2139.txt- the silently discarded packet, and SHOULD record the event
../data/rfc/rfc2139.txt- in a statistics counter.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-2. Operation
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: When a client is configured to use RADIUS Accounting, at the start of
../data/rfc/rfc2139.txt: service delivery it will generate an Accounting Start packet
../data/rfc/rfc2139.txt- describing the type of service being delivered and the user it is
../data/rfc/rfc2139.txt: being delivered to, and will send that to the RADIUS Accounting
../data/rfc/rfc2139.txt- server, which will send back an acknowledgement that the packet has
../data/rfc/rfc2139.txt- been received. At the end of service delivery the client will
../data/rfc/rfc2139.txt: generate an Accounting Stop packet describing the type of service
../data/rfc/rfc2139.txt- that was delivered and optionally statistics such as elapsed time,
../data/rfc/rfc2139.txt- input and output octets, or input and output packets. It will send
../data/rfc/rfc2139.txt: that to the RADIUS Accounting server, which will send back an
../data/rfc/rfc2139.txt- acknowledgement that the packet has been received.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: The Accounting-Request (whether for Start or Stop) is submitted to
../data/rfc/rfc2139.txt: the RADIUS accounting server via the network. It is recommended that
../data/rfc/rfc2139.txt: the client continue attempting to send the Accounting-Request packet
../data/rfc/rfc2139.txt- until it receives an acknowledgement, using some form of backoff. If
../data/rfc/rfc2139.txt- no response is returned within a length of time, the request is re-
../data/rfc/rfc2139.txt- sent a number of times. The client can also forward requests to an
../data/rfc/rfc2139.txt- alternate server or servers in the event that the primary server is
../data/rfc/rfc2139.txt- down or unreachable. An alternate server can be used either after a
../data/rfc/rfc2139.txt- number of tries to the primary server fail, or in a round-robin
../data/rfc/rfc2139.txt- fashion. Retry and fallback algorithms are the topic of current
../data/rfc/rfc2139.txt- research and are not specified in detail in this document.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: The RADIUS accounting server MAY make requests of other servers in
../data/rfc/rfc2139.txt- order to satisfy the request, in which case it acts as a client.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: If the RADIUS accounting server is unable to successfully record the
../data/rfc/rfc2139.txt: accounting packet it MUST NOT send an Accounting-Response
../data/rfc/rfc2139.txt- acknowledgment to the client.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Rigney Informational [Page 4]
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt:RFC 2139 RADIUS Accounting April 1997
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-3. Packet Format
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: Exactly one RADIUS Accounting packet is encapsulated in the UDP Data
../data/rfc/rfc2139.txt- field [1], where the UDP Destination Port field indicates 1813
../data/rfc/rfc2139.txt- (decimal).
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- When a reply is generated, the source and destination ports are
../data/rfc/rfc2139.txt- reversed.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: This memo documents the RADIUS Accounting protocol. There has been
../data/rfc/rfc2139.txt- some confusion in the assignment of port numbers for this protocol.
../data/rfc/rfc2139.txt: The early deployment of RADIUS Accounting was done using the
../data/rfc/rfc2139.txt- erroneously chosen port number 1646, which conflicts with the "sa-
../data/rfc/rfc2139.txt- msg-port" service. The officially assigned port number for RADIUS
../data/rfc/rfc2139.txt: Accounting is 1813.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- A summary of the RADIUS data format is shown below. The fields are
../data/rfc/rfc2139.txt- transmitted from left to right.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- 0 1 2 3
--
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- The Code field is one octet, and identifies the type of RADIUS
../data/rfc/rfc2139.txt- packet. When a packet is received with an invalid Code field, it is
../data/rfc/rfc2139.txt- silently discarded.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: RADIUS Accounting Codes (decimal) are assigned as follows:
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: 4 Accounting-Request
../data/rfc/rfc2139.txt: 5 Accounting-Response
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Identifier
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- The Identifier field is one octet, and aids in matching requests and
../data/rfc/rfc2139.txt- replies.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Rigney Informational [Page 5]
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt:RFC 2139 RADIUS Accounting April 1997
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Length
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- The Length field is two octets. It indicates the length of the
--
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Authenticator
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- The Authenticator field is sixteen (16) octets. The most significant
../data/rfc/rfc2139.txt- octet is transmitted first. This value is used to authenticate the
../data/rfc/rfc2139.txt: messages between the client and RADIUS accounting server.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Request Authenticator
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: In Accounting-Request Packets, the Authenticator value is a 16 octet
../data/rfc/rfc2139.txt- MD5 [3] checksum, called the Request Authenticator.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: The NAS and RADIUS accounting server share a secret. The Request
../data/rfc/rfc2139.txt: Authenticator field in Accounting-Request packets contains a one- way
../data/rfc/rfc2139.txt- MD5 hash calculated over a stream of octets consisting of the Code +
../data/rfc/rfc2139.txt- Identifier + Length + 16 zero octets + request attributes + shared
../data/rfc/rfc2139.txt- secret (where + indicates concatenation). The 16 octet MD5 hash
../data/rfc/rfc2139.txt: value is stored in the Authenticator field of the Accounting-Request
../data/rfc/rfc2139.txt- packet.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: Note that the Request Authenticator of an Accounting-Request can
../data/rfc/rfc2139.txt- not be done the same way as the Request Authenticator of a RADIUS
../data/rfc/rfc2139.txt- Access-Request, because there is no User-Password attribute in an
../data/rfc/rfc2139.txt: Accounting-Request.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Response Authenticator
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: The Authenticator field in an Accounting-Response packet is called
../data/rfc/rfc2139.txt- the Response Authenticator, and contains a one-way MD5 hash
../data/rfc/rfc2139.txt: calculated over a stream of octets consisting of the Accounting-
../data/rfc/rfc2139.txt- Response Code, Identifier, Length, the Request Authenticator field
../data/rfc/rfc2139.txt: from the Accounting-Request packet being replied to, and the response
../data/rfc/rfc2139.txt- attributes if any, followed by the shared secret. The resulting 16
../data/rfc/rfc2139.txt- octet MD5 hash value is stored in the Authenticator field of the
../data/rfc/rfc2139.txt: Accounting-Response packet.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Rigney Informational [Page 6]
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt:RFC 2139 RADIUS Accounting April 1997
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Attributes
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Attributes may have multiple instances, in such a case the order of
--
../data/rfc/rfc2139.txt-4. Packet Types
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- The RADIUS packet type is determined by the Code field in the first
../data/rfc/rfc2139.txt- octet of the packet.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt:4.1. Accounting-Request
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Description
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: Accounting-Request packets are sent from a client (typically a
../data/rfc/rfc2139.txt: Network Access Server or its proxy) to a RADIUS accounting server,
../data/rfc/rfc2139.txt: and convey information used to provide accounting for a service
../data/rfc/rfc2139.txt- provided to a user. The client transmits a RADIUS packet with the
../data/rfc/rfc2139.txt: Code field set to 4 (Accounting-Request).
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: Upon receipt of an Accounting-Request, the server MUST transmit an
../data/rfc/rfc2139.txt: Accounting-Response reply if it successfully records the
../data/rfc/rfc2139.txt: accounting packet, and MUST NOT transmit any reply if it fails to
../data/rfc/rfc2139.txt: record the accounting packet.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Any attribute valid in a RADIUS Access-Request or Access-Accept
../data/rfc/rfc2139.txt: packet is valid in a RADIUS Accounting-Request packet, except that
../data/rfc/rfc2139.txt: the following attributes MUST NOT be present in an Accounting-
../data/rfc/rfc2139.txt- Request: User-Password, CHAP-Password, Reply-Message, State.
../data/rfc/rfc2139.txt- Either NAS-IP-Address or NAS-Identifier MUST be present in a
../data/rfc/rfc2139.txt: RADIUS Accounting-Request. It SHOULD contain a NAS-Port or NAS-
../data/rfc/rfc2139.txt- Port-Type attribute or both unless the service does not involve a
../data/rfc/rfc2139.txt- port or the NAS does not distinguish among its ports.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: A summary of the Accounting-Request packet format is shown below.
../data/rfc/rfc2139.txt- The fields are transmitted from left to right.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
--
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Rigney Informational [Page 7]
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt:RFC 2139 RADIUS Accounting April 1997
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- 0 1 2 3
../data/rfc/rfc2139.txt- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
../data/rfc/rfc2139.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--
../data/rfc/rfc2139.txt- | Attributes ...
../data/rfc/rfc2139.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Code
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: 4 for Accounting-Request.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Identifier
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- The Identifier field MUST be changed whenever the content of the
../data/rfc/rfc2139.txt- Attributes field changes, and whenever a valid reply has been
../data/rfc/rfc2139.txt- received for a previous request. For retransmissions where the
../data/rfc/rfc2139.txt- contents are identical, the Identifier MUST remain unchanged.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Note that if Acct-Delay-Time is included in the attributes of an
../data/rfc/rfc2139.txt: Accounting-Request then the Acct-Delay-Time value will be updated
../data/rfc/rfc2139.txt- when the packet is retransmitted, changing the content of the
../data/rfc/rfc2139.txt- Attributes field and requiring a new Identifier and Request
../data/rfc/rfc2139.txt- Authenticator.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Request Authenticator
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: The Request Authenticator of an Accounting-Request contains a 16-
../data/rfc/rfc2139.txt- octet MD5 hash value calculated according to the method described
../data/rfc/rfc2139.txt- in "Request Authenticator" above.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Attributes
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- The Attributes field is variable in length, and contains a list of
../data/rfc/rfc2139.txt- Attributes.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt:4.2. Accounting-Response
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Description
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: Accounting-Response packets are sent by the RADIUS accounting
../data/rfc/rfc2139.txt: server to the client to acknowledge that the Accounting-Request
../data/rfc/rfc2139.txt: has been received and recorded successfully. If the Accounting-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Rigney Informational [Page 8]
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt:RFC 2139 RADIUS Accounting April 1997
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: Request was recorded successfully then the RADIUS accounting
../data/rfc/rfc2139.txt- server MUST transmit a packet with the Code field set to 5
../data/rfc/rfc2139.txt: (Accounting-Response). On reception of an Accounting-Response by
../data/rfc/rfc2139.txt- the client, the Identifier field is matched with a pending
../data/rfc/rfc2139.txt: Accounting-Request. Invalid packets are silently discarded.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: A RADIUS Accounting-Response is not required to have any
../data/rfc/rfc2139.txt- attributes in it.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: A summary of the Accounting-Response packet format is shown below.
../data/rfc/rfc2139.txt- The fields are transmitted from left to right.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- 0 1 2 3
../data/rfc/rfc2139.txt- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
../data/rfc/rfc2139.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--
../data/rfc/rfc2139.txt- | Attributes ...
../data/rfc/rfc2139.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Code
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: 5 for Accounting-Response.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Identifier
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- The Identifier field is a copy of the Identifier field of the
../data/rfc/rfc2139.txt: Accounting-Request which caused this Accounting-Response.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Response Authenticator
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: The Response Authenticator of an Accounting-Response contains a
../data/rfc/rfc2139.txt- 16-octet MD5 hash value calculated according to the method
../data/rfc/rfc2139.txt- described in "Response Authenticator" above.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Attributes
../data/rfc/rfc2139.txt-
--
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Rigney Informational [Page 9]
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt:RFC 2139 RADIUS Accounting April 1997
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-5. Attributes
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- RADIUS Attributes carry the specific authentication, authorization
../data/rfc/rfc2139.txt: and accounting details for the request and response.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Some attributes MAY be included more than once. The effect of this
../data/rfc/rfc2139.txt- is attribute specific, and is specified in each attribute
../data/rfc/rfc2139.txt- description.
../data/rfc/rfc2139.txt-
--
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Rigney Informational [Page 10]
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt:RFC 2139 RADIUS Accounting April 1997
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Length
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- The Length field is one octet, and indicates the length of this
../data/rfc/rfc2139.txt- attribute including the Type, Length and Value fields. If an
../data/rfc/rfc2139.txt: attribute is received in an Accounting-Request with an invalid
../data/rfc/rfc2139.txt- Length, the entire request should be silently discarded.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Value
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- The Value field is zero or more octets and contains information
--
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-5.1. Acct-Status-Type
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Description
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: This attribute indicates whether this Accounting-Request marks the
../data/rfc/rfc2139.txt- beginning of the user service (Start) or the end (Stop).
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: It MAY be used by the client to mark the start of accounting (for
../data/rfc/rfc2139.txt: example, upon booting) by specifying Accounting-On and to mark the
../data/rfc/rfc2139.txt: end of accounting (for example, just before a scheduled reboot) by
../data/rfc/rfc2139.txt: specifying Accounting-Off.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- A summary of the Acct-Status-Type attribute format is shown below.
../data/rfc/rfc2139.txt- The fields are transmitted from left to right.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- 0 1 2 3
--
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Rigney Informational [Page 11]
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt:RFC 2139 RADIUS Accounting April 1997
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Type
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- 40 for Acct-Status-Type.
--
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- The Value field is four octets.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- 1 Start
../data/rfc/rfc2139.txt- 2 Stop
../data/rfc/rfc2139.txt: 7 Accounting-On
../data/rfc/rfc2139.txt: 8 Accounting-Off
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-5.2. Acct-Delay-Time
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Description
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- This attribute indicates how many seconds the client has been
../data/rfc/rfc2139.txt- trying to send this record for, and can be subtracted from the
../data/rfc/rfc2139.txt- time of arrival on the server to find the approximate time of the
../data/rfc/rfc2139.txt: event generating this Accounting-Request. (Network transit time
../data/rfc/rfc2139.txt- is ignored.)
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Note that changing the Acct-Delay-Time causes the Identifier to
../data/rfc/rfc2139.txt- change; see the discussion under Identifier above.
../data/rfc/rfc2139.txt-
--
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Rigney Informational [Page 12]
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt:RFC 2139 RADIUS Accounting April 1997
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Value
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- The Value field is four octets.
--
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Description
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- This attribute indicates how many octets have been received from
../data/rfc/rfc2139.txt- the port over the course of this service being provided, and can
../data/rfc/rfc2139.txt: only be present in Accounting-Request records where the Acct-
../data/rfc/rfc2139.txt- Status-Type is set to Stop.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- A summary of the Acct-Input-Octets attribute format is shown below.
../data/rfc/rfc2139.txt- The fields are transmitted from left to right.
../data/rfc/rfc2139.txt-
--
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Description
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- This attribute indicates how many octets have been sent to the
../data/rfc/rfc2139.txt- port in the course of delivering this service, and can only be
../data/rfc/rfc2139.txt: present in Accounting-Request records where the Acct-Status-Type
../data/rfc/rfc2139.txt- is set to Stop.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- A summary of the Acct-Output-Octets attribute format is shown below.
../data/rfc/rfc2139.txt- The fields are transmitted from left to right.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Rigney Informational [Page 13]
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt:RFC 2139 RADIUS Accounting April 1997
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- 0 1 2 3
../data/rfc/rfc2139.txt- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
../data/rfc/rfc2139.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-5.5. Acct-Session-Id
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Description
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: This attribute is a unique Accounting ID to make it easy to match
../data/rfc/rfc2139.txt- start and stop records in a log file. The start and stop records
../data/rfc/rfc2139.txt- for a given session MUST have the same Acct-Session-Id. It is
../data/rfc/rfc2139.txt- strongly recommended that the Acct-Session-Id be a printable ASCII
../data/rfc/rfc2139.txt- string.
../data/rfc/rfc2139.txt-
--
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Rigney Informational [Page 14]
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt:RFC 2139 RADIUS Accounting April 1997
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- 0 1 2
../data/rfc/rfc2139.txt- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
../data/rfc/rfc2139.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-5.6. Acct-Authentic
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Description
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: This attribute MAY be included in an Accounting-Request to
../data/rfc/rfc2139.txt- indicate how the user was authenticated, whether by RADIUS, the
../data/rfc/rfc2139.txt- NAS itself, or another remote authentication protocol. Users who
../data/rfc/rfc2139.txt- are delivered service without being authenticated SHOULD NOT
../data/rfc/rfc2139.txt: generate Accounting records.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- A summary of the Acct-Authentic attribute format is shown below. The
../data/rfc/rfc2139.txt- fields are transmitted from left to right.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- 0 1 2 3
--
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Rigney Informational [Page 15]
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt:RFC 2139 RADIUS Accounting April 1997
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Value
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- The Value field is four octets.
--
../data/rfc/rfc2139.txt-5.7. Acct-Session-Time
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Description
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- This attribute indicates how many seconds the user has received
../data/rfc/rfc2139.txt: service for, and can only be present in Accounting-Request records
../data/rfc/rfc2139.txt- where the Acct-Status-Type is set to Stop.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- A summary of the Acct-Session-Time attribute format is shown below.
../data/rfc/rfc2139.txt- The fields are transmitted from left to right.
../data/rfc/rfc2139.txt-
--
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Description
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- This attribute indicates how many packets have been received from
../data/rfc/rfc2139.txt- the port over the course of this service being provided to a
../data/rfc/rfc2139.txt: Framed User, and can only be present in Accounting-Request records
../data/rfc/rfc2139.txt- where the Acct-Status-Type is set to Stop.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Rigney Informational [Page 16]
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt:RFC 2139 RADIUS Accounting April 1997
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- A summary of the Acct-Input-packets attribute format is shown below.
../data/rfc/rfc2139.txt- The fields are transmitted from left to right.
../data/rfc/rfc2139.txt-
--
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Description
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- This attribute indicates how many packets have been sent to the
../data/rfc/rfc2139.txt- port in the course of delivering this service to a Framed User,
../data/rfc/rfc2139.txt: and can only be present in Accounting-Request records where the
../data/rfc/rfc2139.txt- Acct-Status-Type is set to Stop.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- A summary of the Acct-Output-Packets attribute format is shown below.
../data/rfc/rfc2139.txt- The fields are transmitted from left to right.
../data/rfc/rfc2139.txt-
--
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Rigney Informational [Page 17]
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt:RFC 2139 RADIUS Accounting April 1997
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Length
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- 6
--
../data/rfc/rfc2139.txt-5.10. Acct-Terminate-Cause
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Description
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- This attribute indicates how the session was terminated, and can
../data/rfc/rfc2139.txt: only be present in Accounting-Request records where the Acct-
../data/rfc/rfc2139.txt- Status-Type is set to Stop.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- A summary of the Acct-Terminate-Cause attribute format is shown
../data/rfc/rfc2139.txt- below. The fields are transmitted from left to right.
../data/rfc/rfc2139.txt-
--
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Rigney Informational [Page 18]
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt:RFC 2139 RADIUS Accounting April 1997
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Value
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- The Value field is four octets, containing an integer specifying
--
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Rigney Informational [Page 19]
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt:RFC 2139 RADIUS Accounting April 1997
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- NAS Error NAS detected some error (other than on the
../data/rfc/rfc2139.txt- port) which required ending the session.
../data/rfc/rfc2139.txt-
--
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-5.11. Acct-Multi-Session-Id
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Description
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: This attribute is a unique Accounting ID to make it easy to link
../data/rfc/rfc2139.txt- together multiple related sessions in a log file. Each session
../data/rfc/rfc2139.txt- linked together would have a unique Acct-Session-Id but the same
../data/rfc/rfc2139.txt- Acct-Multi-Session-Id. It is strongly recommended that the Acct-
../data/rfc/rfc2139.txt- Multi-Session-Id be a printable ASCII string.
../data/rfc/rfc2139.txt-
--
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Rigney Informational [Page 20]
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt:RFC 2139 RADIUS Accounting April 1997
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Type
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- 50 for Acct-Multi-Session-Id.
--
../data/rfc/rfc2139.txt-5.12. Acct-Link-Count
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Description
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- This attribute gives the count of links which are known to have
../data/rfc/rfc2139.txt: been in a given multilink session at the time the accounting
../data/rfc/rfc2139.txt- record is generated. The NAS MAY include the Acct-Link-Count
../data/rfc/rfc2139.txt: attribute in any Accounting-Request which might have multiple
../data/rfc/rfc2139.txt- links.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- A summary of the Acct-Link-Count attribute format is show below. The
../data/rfc/rfc2139.txt- fields are transmitted from left to right.
../data/rfc/rfc2139.txt-
--
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Rigney Informational [Page 21]
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt:RFC 2139 RADIUS Accounting April 1997
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: It may be used to make it easier for an accounting server to know
../data/rfc/rfc2139.txt- when it has all the records for a given Multilink session. When
../data/rfc/rfc2139.txt: the number of Accounting-Requests received with Acct-Status-Type =
../data/rfc/rfc2139.txt- Stop and the same Acct-Multi-Session-Id and unique Acct-Session-
../data/rfc/rfc2139.txt- Id's equals the largest value of Acct-Link-Count seen in those
../data/rfc/rfc2139.txt: Accounting-Requests, all Stop Accounting-Requests for that
../data/rfc/rfc2139.txt- Multilink Session have been received.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: An example showing 8 Accounting-Requests should make things
../data/rfc/rfc2139.txt- clearer. For clarity only the relevant attributes are shown, but
../data/rfc/rfc2139.txt: additional attributes containing accounting information will also
../data/rfc/rfc2139.txt: be present in the Accounting-Request.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Multi-Session-Id Session-Id Status-Type Link-Count
../data/rfc/rfc2139.txt- "10" "10" Start 1
../data/rfc/rfc2139.txt- "10" "11" Start 2
../data/rfc/rfc2139.txt- "10" "11" Stop 2
--
../data/rfc/rfc2139.txt- "10" "10" Stop 4
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-5.13. Table of Attributes
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- The following table provides a guide to which attributes may be found
../data/rfc/rfc2139.txt: in Accounting-Request packets. No attributes should be found in
../data/rfc/rfc2139.txt: Accounting-Response packets except Proxy-State and possibly Vendor-
../data/rfc/rfc2139.txt- Specific.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- # Attribute
../data/rfc/rfc2139.txt- 0-1 User-Name
../data/rfc/rfc2139.txt- 0 User-Password
--
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Rigney Informational [Page 22]
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt:RFC 2139 RADIUS Accounting April 1997
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- 0-1 Callback-Number
../data/rfc/rfc2139.txt- 0-1 Callback-Id
../data/rfc/rfc2139.txt- 0+ Framed-Route
--
../data/rfc/rfc2139.txt- 0-1 NAS-Port-Type
../data/rfc/rfc2139.txt- 0-1 Port-Limit
../data/rfc/rfc2139.txt- 0-1 Login-LAT-Port
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: [5] An Accounting-Request MUST contain either a NAS-IP-Address or a
../data/rfc/rfc2139.txt- NAS-Identifier, and it is permitted (but not recommended) for it to
../data/rfc/rfc2139.txt- contain both.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- The following table defines the above table entries.
../data/rfc/rfc2139.txt-
--
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Rigney Informational [Page 23]
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt:RFC 2139 RADIUS Accounting April 1997
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Security Considerations
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Security issues are briefly discussed in sections concerning the
../data/rfc/rfc2139.txt: authenticator included in accounting requests and responses, using a
../data/rfc/rfc2139.txt- shared secret which is never sent over the network.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-References
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- [1] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
--
../data/rfc/rfc2139.txt- Authentication Dial In User Service (RADIUS)", RFC 2138,
../data/rfc/rfc2139.txt- April 1997.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Acknowledgments
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt: RADIUS and RADIUS Accounting were originally developed by Livingston
../data/rfc/rfc2139.txt- Enterprises for their PortMaster series of Network Access Servers.
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Chair's Address
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- The RADIUS working group can be contacted via the current chair:
--
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Rigney Informational [Page 24]
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt:RFC 2139 RADIUS Accounting April 1997
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt-Author's Address
../data/rfc/rfc2139.txt-
../data/rfc/rfc2139.txt- Questions about this memo can also be directed to:
--
../data/rfc/rfc4220.txt- DISPLAY-HINT "d"
../data/rfc/rfc4220.txt- STATUS current
../data/rfc/rfc4220.txt- DESCRIPTION
../data/rfc/rfc4220.txt- "This type is used to represent a priority. Each connection
../data/rfc/rfc4220.txt- is assigned a priority. This priority is used when
../data/rfc/rfc4220.txt: accounting for bandwidth on TE links or component
../data/rfc/rfc4220.txt- links, for resource allocation and for rerouting purposes.
../data/rfc/rfc4220.txt- Value 0 is the highest priority. Value 7 is the lowest
../data/rfc/rfc4220.txt- priority."
../data/rfc/rfc4220.txt-
../data/rfc/rfc4220.txt-
--
../data/rfc/rfc7182.txt-
../data/rfc/rfc7182.txt- o Two kinds of TLV: one for carrying Integrity Check Values (ICVs)
../data/rfc/rfc7182.txt- and one for timestamps in packets, messages, and Address Blocks as
../data/rfc/rfc7182.txt- defined by [RFC5444].
../data/rfc/rfc7182.txt-
../data/rfc/rfc7182.txt: o A generic framework for use of these TLVs, accounting for specific
../data/rfc/rfc7182.txt- features of Packet, Message, and Address Block TLVs.
../data/rfc/rfc7182.txt-
../data/rfc/rfc7182.txt- o IANA registrations for TLVs, and registries for TLV type
../data/rfc/rfc7182.txt- extensions, replacing those from [RFC6622].
../data/rfc/rfc7182.txt-
--
../data/rfc/rfc6521.txt-
../data/rfc/rfc6521.txt-
../data/rfc/rfc6521.txt- Several possibilities exist for achieving route optimization between
../data/rfc/rfc6521.txt- MRs attached to separate HAs, such as a new discovery/probing
../data/rfc/rfc6521.txt- protocol or routing protocol between HAs or DNS SRV records, or a
../data/rfc/rfc6521.txt: common Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc6521.txt- architecture. There is already a framework for HA to retrieve
../data/rfc/rfc6521.txt- information from AAA, so it can be considered the most viable
../data/rfc/rfc6521.txt- possibility. See Section 6.6 for information on a possible way to
../data/rfc/rfc6521.txt- generalize the method.
../data/rfc/rfc6521.txt-
--
../data/rfc/rfc3603.txt- information, and station information (e.g., coin operated phone). In
../data/rfc/rfc3603.txt- addition, while translating the destination number, information such
../data/rfc/rfc3603.txt- as the local-number-portability office code is obtained and will be
../data/rfc/rfc3603.txt- needed by all other proxies handling this call.
../data/rfc/rfc3603.txt-
../data/rfc/rfc3603.txt: For Usage Accounting records, it is necessary to have an identifier
../data/rfc/rfc3603.txt- that can be associated with all the event records produced for the
../data/rfc/rfc3603.txt- call. The SIP Call-ID header field cannot be used as such an
../data/rfc/rfc3603.txt- identifier since it is selected by the originating user agent, and
../data/rfc/rfc3603.txt- may not be unique among all past calls as well as current calls.
../data/rfc/rfc3603.txt- Further, since this identifier is to be used by the service provider,
--
../data/rfc/rfc3603.txt- announcement servers, etc. Outside of the trust boundary lie the
../data/rfc/rfc3603.txt- customer premises equipment, and various application and media
../data/rfc/rfc3603.txt- servers operated by third-party service providers.
../data/rfc/rfc3603.txt-
../data/rfc/rfc3603.txt- Certain subscriber-specific information, such as billing and
../data/rfc/rfc3603.txt: accounting information, stays within the trust boundary. Other
../data/rfc/rfc3603.txt- subscriber-specific information, such as endpoint identity, may be
../data/rfc/rfc3603.txt- presented to untrusted endpoints or may be withheld based on
../data/rfc/rfc3603.txt- subscriber profiles.
../data/rfc/rfc3603.txt-
../data/rfc/rfc3603.txt- The User Agent (UA) may be either within the trust boundary or
--
../data/rfc/rfc3603.txt- information based on the authenticated identity of the calling and
../data/rfc/rfc3603.txt- called parties. Since there is a trust relationship among proxies,
../data/rfc/rfc3603.txt- they can be relied upon to exchange trusted billing information
../data/rfc/rfc3603.txt- pertaining to the parties involved in a call.
../data/rfc/rfc3603.txt-
../data/rfc/rfc3603.txt: For Usage Accounting records, it is necessary to have an identifier
../data/rfc/rfc3603.txt- that can be associated with all the event records produced for the
../data/rfc/rfc3603.txt- call. The SIP Call-ID header field cannot be used as such an
../data/rfc/rfc3603.txt- identifier since it is selected by the originating user agent, and
../data/rfc/rfc3603.txt- may not be unique among all past calls as well as current calls.
../data/rfc/rfc3603.txt- Further, since this identifier is to be used by the service provider,
--
../data/rfc/rfc3603.txt- the future, to limit the ability of the originator to re-use this
../data/rfc/rfc3603.txt- private-URL for multiple calls.
../data/rfc/rfc3603.txt-
../data/rfc/rfc3603.txt- A UAC that includes a Refer-to header in a REFER request MUST include
../data/rfc/rfc3603.txt- a P-DCS-Billing-Info header in the Refer-to's URL. This P-DCS-
../data/rfc/rfc3603.txt: Billing-Info header MUST include the accounting information of the
../data/rfc/rfc3603.txt- initiator of the REFER.
../data/rfc/rfc3603.txt-
../data/rfc/rfc3603.txt-7.4. Procedures at an Untrusted User Agent Server (UAS)
../data/rfc/rfc3603.txt-
../data/rfc/rfc3603.txt- This header is never sent to an untrusted UAS, and is never sent by
--
../data/rfc/rfc3603.txt- provisioned in the UAS. If the UAS performed a LNP query, it MUST
../data/rfc/rfc3603.txt- include the Routing Number and Location Routing Number returned by
../data/rfc/rfc3603.txt- the query.
../data/rfc/rfc3603.txt-
../data/rfc/rfc3603.txt- The UAS MUST add a P-DCS-Billing-Info header to a 3xx-redirect
../data/rfc/rfc3603.txt: response to an initial INVITE, giving the accounting information for
../data/rfc/rfc3603.txt- the call forwarder, for the call segment from the destination to the
../data/rfc/rfc3603.txt- forwarded-to destination.
../data/rfc/rfc3603.txt-
../data/rfc/rfc3603.txt-
../data/rfc/rfc3603.txt-
--
../data/rfc/rfc3603.txt- Info header present from an untrusted UA MUST be removed.
../data/rfc/rfc3603.txt-
../data/rfc/rfc3603.txt- If the Request-URI contains a private-URL, and the decoded username
../data/rfc/rfc3603.txt- contains billing information, the originating proxy MUST generate a
../data/rfc/rfc3603.txt- P-DCS-Billing-Info header with that decrypted information. Otherwise,
../data/rfc/rfc3603.txt: the originating proxy MUST determine the accounting information for
../data/rfc/rfc3603.txt- the call originator, and insert a P-DCS-Billing-Info header including
../data/rfc/rfc3603.txt- that information.
../data/rfc/rfc3603.txt-
../data/rfc/rfc3603.txt-
../data/rfc/rfc3603.txt-
--
../data/rfc/rfc3603.txt- the future, to limit the ability of the originator to re-use this
../data/rfc/rfc3603.txt- private-URL for multiple calls.
../data/rfc/rfc3603.txt-
../data/rfc/rfc3603.txt- An originating proxy that processes a REFER request from an untrusted
../data/rfc/rfc3603.txt- UA MUST include a P-DCS-Billing-Info header in the Refer-to's URL.
../data/rfc/rfc3603.txt: This P-DCS-Billing-Info header MUST include the accounting
../data/rfc/rfc3603.txt- information of the initiator.
../data/rfc/rfc3603.txt-
../data/rfc/rfc3603.txt-7.6.2. Procedures at Terminating Proxy
../data/rfc/rfc3603.txt-
../data/rfc/rfc3603.txt- The terminating proxy MUST NOT send the P-DCS-Billing-Info header to
--
../data/rfc/rfc3603.txt- provider policy provisioned in the terminating proxy. If the
../data/rfc/rfc3603.txt- terminating proxy performed a LNP query, it MUST include the Routing
../data/rfc/rfc3603.txt- Number and Location Routing Number returned by the query.
../data/rfc/rfc3603.txt-
../data/rfc/rfc3603.txt- The terminating proxy MUST add P-DCS-Billing-Info headers to a 3xx-
../data/rfc/rfc3603.txt: redirect response to an initial INVITE, giving the accounting
../data/rfc/rfc3603.txt- information for the call forwarder, for the call segment from the
../data/rfc/rfc3603.txt- destination to the forwarded-to destination.
../data/rfc/rfc3603.txt-
../data/rfc/rfc3603.txt-
../data/rfc/rfc3603.txt-
--
../data/rfc/rfc2626.txt-
../data/rfc/rfc2626.txt- for IPng
../data/rfc/rfc2626.txt-1676:: I:: INFN Requirements for an IPng
../data/rfc/rfc2626.txt-1674:: I:: A Cellular Industry View of IPng
../data/rfc/rfc2626.txt-1673:: I:: Electric Power Research Institute Comments on IPng
../data/rfc/rfc2626.txt:1672:: I:: Accounting Requirements for IPng
../data/rfc/rfc2626.txt-1671:: I:: IPng White Paper on Transition and Other Considerations
../data/rfc/rfc2626.txt-1670:: I:: Input to IPng Engineering Considerations
../data/rfc/rfc2626.txt-1669:: I:: Market Viability as a IPng Criteria
../data/rfc/rfc2626.txt-1667:: I:: Modeling and Simulation Requirements for IPng
../data/rfc/rfc2626.txt-1663:: PS:: PPP Reliable Transmission
--
../data/rfc/rfc2626.txt-1354:: PS:: IP Forwarding Table MIB
../data/rfc/rfc2626.txt-1353:: H:: Definitions of Managed Objects for Administration of
../data/rfc/rfc2626.txt- SNMP Parties
../data/rfc/rfc2626.txt-1352:: H:: SNMP Security Protocols
../data/rfc/rfc2626.txt-1351:: H:: SNMP Administrative Model
../data/rfc/rfc2626.txt:1346:: I:: Resource Allocation, Control, and Accounting for the
../data/rfc/rfc2626.txt- Use of Network Resources
../data/rfc/rfc2626.txt-1318:: PS:: Definitions of Managed Objects for Parallel-printer-like
../data/rfc/rfc2626.txt-
../data/rfc/rfc2626.txt-
../data/rfc/rfc2626.txt-
--
../data/rfc/rfc2626.txt-1284:: PS:: Definitions of Managed Objects for the Ethernet-like
../data/rfc/rfc2626.txt- Interface Types
../data/rfc/rfc2626.txt-1283:: E:: SNMP over OSI
../data/rfc/rfc2626.txt-1273:: I:: A Measurement Study of Changes in Service-Level
../data/rfc/rfc2626.txt- Reachability in the Global TCP/IP Internet
../data/rfc/rfc2626.txt:1272:: I:: Internet Accounting
../data/rfc/rfc2626.txt-1271:: PS:: Remote Network Monitoring Management Information Base
../data/rfc/rfc2626.txt-1270:: I:: SNMP Communications Services
../data/rfc/rfc2626.txt-1269:: PS:: Definitions of Managed Objects for the Border Gateway
../data/rfc/rfc2626.txt- Protocol (Version 3)
../data/rfc/rfc2626.txt-1262:: :: Guidelines for Internet Measurement Activities
--
../data/rfc/rfc2626.txt-2082:: PS:: RIP-2 MD5 Authentication
../data/rfc/rfc2626.txt-2078:: PS:: Generic Security Service Application Program Interface,
../data/rfc/rfc2626.txt- Version 2
../data/rfc/rfc2626.txt-2069:: PS:: An Extension to HTTP
../data/rfc/rfc2626.txt-2065:: PS:: Domain Name System Security Extensions
../data/rfc/rfc2626.txt:2059:: I:: RADIUS Accounting
../data/rfc/rfc2626.txt-2058:: PS:: Remote Authentication Dial In User Service (RADIUS)
../data/rfc/rfc2626.txt-2057:: I:: Source directed access control on the Internet.
../data/rfc/rfc2626.txt-2040:: I:: The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms
../data/rfc/rfc2626.txt-2025:: PS:: The Simple Public-Key GSS-API Mechanism (SPKM)
../data/rfc/rfc2626.txt-2015:: :: MIME Security with Pretty Good Privacy (PGP)
--
../data/rfc/rfc2626.txt-Nesser Informational [Page 76]
../data/rfc/rfc2626.txt-
../data/rfc/rfc2626.txt-RFC 2626 The Internet and the Millennium Problem (Year 2000) June 1999
../data/rfc/rfc2626.txt-
../data/rfc/rfc2626.txt-
../data/rfc/rfc2626.txt: 136:: :: Host accounting and administrative procedures
../data/rfc/rfc2626.txt- 135:: :: Response to NWG/RFC 110
../data/rfc/rfc2626.txt- 132:: :: Typographical error in RFC 107
../data/rfc/rfc2626.txt- 131:: :: Response to RFC 116
../data/rfc/rfc2626.txt- 130:: :: Response to RFC 111
../data/rfc/rfc2626.txt- 129:: :: Request for comments on socket name structure
--
../data/rfc/rfc2906.txt- Copyright (C) The Internet Society (2000). All Rights Reserved.
../data/rfc/rfc2906.txt-
../data/rfc/rfc2906.txt-Abstract
../data/rfc/rfc2906.txt-
../data/rfc/rfc2906.txt- This document specifies the requirements that Authentication
../data/rfc/rfc2906.txt: Authorization Accounting (AAA) protocols must meet in order to
../data/rfc/rfc2906.txt- support authorization services in the Internet. The requirements have
../data/rfc/rfc2906.txt- been elicited from a study of a range of applications including
../data/rfc/rfc2906.txt- mobile-IP, roamops and others.
../data/rfc/rfc2906.txt-
../data/rfc/rfc2906.txt-
--
../data/rfc/rfc2906.txt- different (security) domains.
../data/rfc/rfc2906.txt-
../data/rfc/rfc2906.txt- This states that it must be possible for any AAA protocol message to
../data/rfc/rfc2906.txt- cross security or administrative domain boundaries. Typically, higher
../data/rfc/rfc2906.txt- levels of security will be applied when crossing such boundaries, and
../data/rfc/rfc2906.txt: accounting mechanisms may also have to be more stringent.
../data/rfc/rfc2906.txt-
../data/rfc/rfc2906.txt-2.4.4 AAA protocols MUST support roaming.
../data/rfc/rfc2906.txt-
../data/rfc/rfc2906.txt- Roaming here may also be thought of as "away-from-home" operation.
../data/rfc/rfc2906.txt- For example, this is a fundamental requirement for the mobile IP
--
../data/rfc/rfc2906.txt-
../data/rfc/rfc2906.txt- This states that AAA entities may have to maintain state and act when
../data/rfc/rfc2906.txt- the state indicates some condition has been met.
../data/rfc/rfc2906.txt-
../data/rfc/rfc2906.txt-2.7.3 Within a single session or transaction, it MUST be possible to
../data/rfc/rfc2906.txt: interleave authentication, authorization and accounting AAA messages.
../data/rfc/rfc2906.txt-
../data/rfc/rfc2906.txt- This states, that e.g. a session may have to use initial
../data/rfc/rfc2906.txt: authentication, authorization and accounting AAA message(s), but also
../data/rfc/rfc2906.txt- have to include e.g. re-authentication every 30 minutes, or a
../data/rfc/rfc2906.txt: continuous "drip-drip" of accounting AAA messages.
../data/rfc/rfc2906.txt-
../data/rfc/rfc2906.txt-2.7.4 Authorization decisions may result in a "not ready" answer.
../data/rfc/rfc2906.txt-
../data/rfc/rfc2906.txt- This states that yes and no are not the only outcomes of an
../data/rfc/rfc2906.txt- authorization decision. In particular, if the AAA entity cannot yet
--
../data/rfc/rfc2906.txt-
../data/rfc/rfc2906.txt- This is necessary to be able to scale a AAA solution where there are
../data/rfc/rfc2906.txt- many requestors.
../data/rfc/rfc2906.txt-
../data/rfc/rfc2906.txt-2.10.4 AAA protocols MUST be able to support a linkage between
../data/rfc/rfc2906.txt: authorization and accounting mechanisms.
../data/rfc/rfc2906.txt-
../data/rfc/rfc2906.txt- Motherhood and apple-pie.
../data/rfc/rfc2906.txt-
../data/rfc/rfc2906.txt-
../data/rfc/rfc2906.txt-
--
../data/rfc/rfc2906.txt-3. Security Considerations
../data/rfc/rfc2906.txt-
../data/rfc/rfc2906.txt- This document includes specific security requirements.
../data/rfc/rfc2906.txt-
../data/rfc/rfc2906.txt- This document does not state any detailed requirements for the
../data/rfc/rfc2906.txt: interplay with authentication, accounting or accountability (audit).
../data/rfc/rfc2906.txt- A AAA protocol, which meets all of the above requirements, may still
../data/rfc/rfc2906.txt- leave vulnerabilities due to such interactions. Such issues must be
../data/rfc/rfc2906.txt- considered as part of AAA protocol design.
../data/rfc/rfc2906.txt-
../data/rfc/rfc2906.txt-
--
../data/rfc/rfc7906.txt- The integer encoding should be used when it is important to
../data/rfc/rfc7906.txt- keep key package size to a minimum.
../data/rfc/rfc7906.txt-
../data/rfc/rfc7906.txt- o The registerID is OPTIONAL. For electronic keying material,
../data/rfc/rfc7906.txt- the registerID is usually omitted. The registerID is an
../data/rfc/rfc7906.txt: accounting number assigned to identify Communications Security
../data/rfc/rfc7906.txt- (COMSEC) material. The registerID is either a single value or
../data/rfc/rfc7906.txt- a range.
../data/rfc/rfc7906.txt-
../data/rfc/rfc7906.txt- o The segmentID is OPTIONAL, and it distinguishes the individual
../data/rfc/rfc7906.txt- symmetric keys delivered in one edition. A unique
--
../data/rfc/rfc6942.txt- with an unknown EAP code.
../data/rfc/rfc6942.txt-
../data/rfc/rfc6942.txt-10. IANA Considerations
../data/rfc/rfc6942.txt-
../data/rfc/rfc6942.txt- IANA has registered the following new elements in the Authentication,
../data/rfc/rfc6942.txt: Authorization, and Accounting (AAA) Parameters registries
../data/rfc/rfc6942.txt- [AAAPARAMS].
../data/rfc/rfc6942.txt-
../data/rfc/rfc6942.txt-10.1. Diameter Application Identifier
../data/rfc/rfc6942.txt-
../data/rfc/rfc6942.txt- IANA has allocated a new value "Diameter ERP" (code: 13) in the
--
../data/rfc/rfc6942.txt- October 2012.
../data/rfc/rfc6942.txt-
../data/rfc/rfc6942.txt-14.2. Informative References
../data/rfc/rfc6942.txt-
../data/rfc/rfc6942.txt- [AAAPARAMS] Internet Assigned Numbers Authority, "Authentication,
../data/rfc/rfc6942.txt: Authorization, and Accounting (AAA) Parameters",
../data/rfc/rfc6942.txt- <http://www.iana.org/assignments/aaa-parameters/>.
../data/rfc/rfc6942.txt-
../data/rfc/rfc6942.txt- [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
../data/rfc/rfc6942.txt- Arkko, "Diameter Base Protocol", RFC 3588, September
../data/rfc/rfc6942.txt- 2003.
--
../data/rfc/rfc231.txt-could be taken to constructing a uniform access to subsystems from the
../data/rfc/rfc231.txt-supervisor. In like fashion, a network standard interrupt could be
../data/rfc/rfc231.txt-translated into the escape (e.g., control C) of the serving host to
../data/rfc/rfc231.txt-return from a subsystem.
../data/rfc/rfc231.txt-
../data/rfc/rfc231.txt:Charging Algorithms and Accounting Protocol
../data/rfc/rfc231.txt--------------------------------------------
../data/rfc/rfc231.txt-
../data/rfc/rfc231.txt- To accurately forecast costs, a normalized formula for machine
../data/rfc/rfc231.txt-
../data/rfc/rfc231.txt-
../data/rfc/rfc231.txt-
../data/rfc/rfc231.txt- [Page 2]
../data/rfc/rfc231.txt-
../data/rfc/rfc231.txt:time estimation is needed. Technically, an accounting protocol is
../data/rfc/rfc231.txt-easily added at the subnet and/or NCP levels--the relevant information
../data/rfc/rfc231.txt-is the same for all nodes, thus the Net charges are readily determined
../data/rfc/rfc231.txt-by any node. More difficult is the prediction and comparison of host
../data/rfc/rfc231.txt-charges. Like the login procedure example, each host uses the same
../data/rfc/rfc231.txt-ingredients, namely storage, I/O, connect time, and CPU resources
../data/rfc/rfc231.txt-expended. Again, like the login procedure the information is handled
../data/rfc/rfc231.txt-slightly dif- ferently in each case such that estimations are
../data/rfc/rfc231.txt-difficult. For example, some charge algorithms represent I/O as
../data/rfc/rfc231.txt-counts of I/O transactions where others clock I/O time. Without
../data/rfc/rfc231.txt:significantly perturbing anyone's local accounting proce- dures, it is
../data/rfc/rfc231.txt-desirable to normalize the charge components as a step toward
../data/rfc/rfc231.txt-reasonable cost comparisons and forecast- ing.
../data/rfc/rfc231.txt-
../data/rfc/rfc231.txt-Off-Line Services
../data/rfc/rfc231.txt------------------ .
--
../data/rfc/rfc7378.txt- calls, even for customers with whom they have no direct or indirect
../data/rfc/rfc7378.txt- relationship. To provide identity information about the emergency
../data/rfc/rfc7378.txt- caller from the VSP, it would be necessary to let the IAP and the VSP
../data/rfc/rfc7378.txt- interact for authentication (see, for example, "Diameter Session
../data/rfc/rfc7378.txt- Initiation Protocol (SIP) Application" [RFC4740]). This interaction
../data/rfc/rfc7378.txt: along the Authentication, Authorization, and Accounting
../data/rfc/rfc7378.txt- infrastructure is often based on business relationships between the
../data/rfc/rfc7378.txt- involved entities. An arbitrary IAP and VSP are unlikely to have a
../data/rfc/rfc7378.txt- business relationship. If the interaction between the IAP and the
../data/rfc/rfc7378.txt- VSP fails due to the lack of a business relationship, then typically
../data/rfc/rfc7378.txt- a fall-back would be provided where no emergency caller identity
--
../data/rfc/rfc5418.txt- authenticate prior to being granted access, and in enterprise
../data/rfc/rfc5418.txt- deployments, this is frequently accomplished using [8021X]. When
../data/rfc/rfc5418.txt- using IEEE 802.11, this mode is called a Robust Security Network
../data/rfc/rfc5418.txt- (RSN) [80211I]. Here, the client is called the "supplicant", the AP
../data/rfc/rfc5418.txt- is the "authenticator", and either the AP or an external
../data/rfc/rfc5418.txt: Authentication, Authorization, and Accounting (AAA) server fulfill
../data/rfc/rfc5418.txt- the role of "authentication server", depending on the authentication
../data/rfc/rfc5418.txt- mechanism used.
../data/rfc/rfc5418.txt-
../data/rfc/rfc5418.txt- From the perspective of the network administrator, the wired LAN to
../data/rfc/rfc5418.txt- which the AP is attached is typically considered to be more trusted
--
../data/rfc/rfc5418.txt-RFC 5418 CAPWAP 802.11 Threat Analysis March 2009
../data/rfc/rfc5418.txt-
../data/rfc/rfc5418.txt-
../data/rfc/rfc5418.txt-2. Abbreviations and Definitions
../data/rfc/rfc5418.txt-
../data/rfc/rfc5418.txt: o AAA - Authentication Authorization and Accounting
../data/rfc/rfc5418.txt-
../data/rfc/rfc5418.txt- o AC - Access Controller
../data/rfc/rfc5418.txt-
../data/rfc/rfc5418.txt- o AES-CCMP - Advanced Encryption Standard - Counter-mode CBC MAC
../data/rfc/rfc5418.txt- Protocol
--
../data/rfc/rfc5418.txt- [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
../data/rfc/rfc5418.txt- Authentication Protocol (EAP) Application", RFC 4072,
../data/rfc/rfc5418.txt- August 2005.
../data/rfc/rfc5418.txt-
../data/rfc/rfc5418.txt- [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
../data/rfc/rfc5418.txt: Authorization, and Accounting (AAA) Key Management",
../data/rfc/rfc5418.txt- BCP 132, RFC 4962, July 2007.
../data/rfc/rfc5418.txt-
../data/rfc/rfc5418.txt-
../data/rfc/rfc5418.txt-
../data/rfc/rfc5418.txt-
--
../data/rfc/rfc1550.txt-
../data/rfc/rfc1550.txt- 5.11 Datagram service - Existing IP service is "best effort" and
../data/rfc/rfc1550.txt- based on hop-by-hop routed datagrams. What requirements for this
../data/rfc/rfc1550.txt- paradigm influence the IPng selection?
../data/rfc/rfc1550.txt-
../data/rfc/rfc1550.txt: 5.12 Accounting - How important a consideration should the ability to
../data/rfc/rfc1550.txt: do accounting be in the selection of an IPng? What, if any,
../data/rfc/rfc1550.txt: features should be included in an IPng to support accounting
../data/rfc/rfc1550.txt- functions?
../data/rfc/rfc1550.txt-
../data/rfc/rfc1550.txt- 5.13 Support of communication media - IPv4 can be supported over most
../data/rfc/rfc1550.txt- known types of communications media. How important is this same
../data/rfc/rfc1550.txt- flexibility to an IPng?
--
../data/rfc/rfc3387.txt- The majority of current activity on higher level management functions
../data/rfc/rfc3387.txt- for IP networks have been restricted to the issue of providing QoS.
../data/rfc/rfc3387.txt- Many service issues still remain to be resolved with respect to the
../data/rfc/rfc3387.txt- current best effort paradigm and many more can be expected if true
../data/rfc/rfc3387.txt- QoS support is realized. Authentication, authorization and
../data/rfc/rfc3387.txt: accounting services still inadequate for the existing best effort
../data/rfc/rfc3387.txt- service will need additional work to support QoS services.
../data/rfc/rfc3387.txt-
../data/rfc/rfc3387.txt- It is reasonable that services can be classified into application
../data/rfc/rfc3387.txt- level services and transport level services. Transport services are
../data/rfc/rfc3387.txt- the services that the network provides independent of any
--
../data/rfc/rfc3387.txt- the configuration of a path between two endpoints. Even within this
../data/rfc/rfc3387.txt- limited scope there still remains many unresolved issues. There is
../data/rfc/rfc3387.txt- no expectation that a QoS path for traffic between two points needs
../data/rfc/rfc3387.txt- to be, or should be, the same in both directions. Given that there
../data/rfc/rfc3387.txt- will be an originator of the connection there are questions about how
../data/rfc/rfc3387.txt: billing and accounting with be resolved if the return path is
../data/rfc/rfc3387.txt- established by a different provider then that of the originator of
../data/rfc/rfc3387.txt- the connection. To facilitate billing a method will need to exist
../data/rfc/rfc3387.txt- that permits the application originating the call to pay also for the
../data/rfc/rfc3387.txt- return path and also for collect calls to be made. 3rd party
../data/rfc/rfc3387.txt-
--
../data/rfc/rfc3387.txt- configuration, fault detection, and recovery. Network devices will
../data/rfc/rfc3387.txt- need to inform the management system of their available resources and
../data/rfc/rfc3387.txt- the management system will need to tell devices how and where to
../data/rfc/rfc3387.txt- forward data.
../data/rfc/rfc3387.txt-
../data/rfc/rfc3387.txt: Between administrative regions accounting, service signaling, and
../data/rfc/rfc3387.txt- service verification will be needed. At the administrative
../data/rfc/rfc3387.txt- boundaries of the network functions similar to those provided at the
../data/rfc/rfc3387.txt- edge will be necessary. Peer entities in different administrative
../data/rfc/rfc3387.txt- domains would signal their needs across the boundary. Verification
../data/rfc/rfc3387.txt- at the boundary could then occur consistent with the verification at
--
../data/rfc/rfc6622.txt- This document specifies
../data/rfc/rfc6622.txt-
../data/rfc/rfc6622.txt- o Two TLVs for carrying Integrity Check Values (ICVs) and timestamps
../data/rfc/rfc6622.txt- in packets, messages, and address blocks as defined by [RFC5444].
../data/rfc/rfc6622.txt-
../data/rfc/rfc6622.txt: o A generic framework for ICVs, accounting (for Message TLVs) for
../data/rfc/rfc6622.txt- mutable message header fields (<msg-hop-limit> and
../data/rfc/rfc6622.txt- <msg-hop-count>), where these fields are present in messages.
../data/rfc/rfc6622.txt-
../data/rfc/rfc6622.txt- This document sets up IANA registries for recording code points for
../data/rfc/rfc6622.txt- hash-function and ICV calculation, respectively.
--
../data/rfc/rfc2210.txt-
../data/rfc/rfc2210.txt- Several types of data must be transported between applications and
../data/rfc/rfc2210.txt- network elements to correctly invoke QoS control services.
../data/rfc/rfc2210.txt-
../data/rfc/rfc2210.txt- NOTE: In addition to the data used to directly invoke QoS control
../data/rfc/rfc2210.txt: services, RSVP carries authentication, accounting, and policy
../data/rfc/rfc2210.txt- information needed to manage the use of these services. This note
../data/rfc/rfc2210.txt- is concerned only with the RSVP objects needed to actually invoke
../data/rfc/rfc2210.txt: QoS control services, and does not discuss accounting or policy
../data/rfc/rfc2210.txt- objects.
../data/rfc/rfc2210.txt-
../data/rfc/rfc2210.txt- This data includes:
../data/rfc/rfc2210.txt-
../data/rfc/rfc2210.txt- - Information generated by each receiver describing the QoS
--
../data/rfc/rfc4655.txt- For example, stateless PCEs may compute paths based on current TED
../data/rfc/rfc4655.txt- information, which could be out of sync with actual network state
../data/rfc/rfc4655.txt- given other recent PCE-computed paths changes. Note that a PCC may
../data/rfc/rfc4655.txt- include a set of previously computed paths in its request, in order
../data/rfc/rfc4655.txt- to take them into account, for instance, to avoid double bandwidth
../data/rfc/rfc4655.txt: accounting or to try to minimize changes (minimum perturbation
../data/rfc/rfc4655.txt- problem).
../data/rfc/rfc4655.txt-
../data/rfc/rfc4655.txt-
../data/rfc/rfc4655.txt-
../data/rfc/rfc4655.txt-
--
../data/rfc/rfc4072.txt- 2.3.3. Scenario 3: Direct EAP, Authorization via Agents ..9
../data/rfc/rfc4072.txt- 2.3.4. Scenario 4: Proxy Agents .........................10
../data/rfc/rfc4072.txt- 2.4. Invalid Packets .........................................10
../data/rfc/rfc4072.txt- 2.5. Retransmission ..........................................11
../data/rfc/rfc4072.txt- 2.6. Fragmentation ...........................................12
../data/rfc/rfc4072.txt: 2.7. Accounting ..............................................12
../data/rfc/rfc4072.txt- 2.8. Usage Guidelines ........................................13
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt-Eronen, et al. Standards Track [Page 1]
--
../data/rfc/rfc4072.txt- 4.1. New AVPs ................................................18
../data/rfc/rfc4072.txt- 4.1.1. EAP-Payload AVP ..................................18
../data/rfc/rfc4072.txt- 4.1.2. EAP-Reissued-Payload AVP .........................18
../data/rfc/rfc4072.txt- 4.1.3. EAP-Master-Session-Key AVP .......................19
../data/rfc/rfc4072.txt- 4.1.4. EAP-Key-Name AVP .................................19
../data/rfc/rfc4072.txt: 4.1.5. Accounting-EAP-Auth-Method AVP ...................19
../data/rfc/rfc4072.txt- 5. AVP Occurrence Tables .........................................19
../data/rfc/rfc4072.txt- 5.1. EAP Command AVP Table ...................................20
../data/rfc/rfc4072.txt: 5.2. Accounting AVP Table ....................................21
../data/rfc/rfc4072.txt- 6. RADIUS/Diameter Interactions ..................................22
../data/rfc/rfc4072.txt- 6.1. RADIUS Request Forwarded as Diameter Request ............22
../data/rfc/rfc4072.txt- 6.2. Diameter Request Forwarded as RADIUS Request ............23
../data/rfc/rfc4072.txt: 6.3. Accounting Requests .....................................24
../data/rfc/rfc4072.txt- 7. IANA Considerations ...........................................24
../data/rfc/rfc4072.txt- 8. Security Considerations .......................................24
../data/rfc/rfc4072.txt- 8.1. Overview ................................................24
../data/rfc/rfc4072.txt- 8.2. AVP Editing .............................................26
../data/rfc/rfc4072.txt- 8.3. Negotiation Attacks .....................................27
--
../data/rfc/rfc4072.txt- 802.11, the RADIUS server may send an EAP packet as large as
../data/rfc/rfc4072.txt- Framed-MTU minus four (4) octets, taking into account the additional
../data/rfc/rfc4072.txt- overhead for the IEEE 802.1X Version (1 octet), Type (1 octet) and
../data/rfc/rfc4072.txt- Body Length (2 octets) fields.
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt:2.7. Accounting
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt- When a user is authenticated using EAP, the NAS MAY include an
../data/rfc/rfc4072.txt: Accounting-Auth-Method AVP [NASREQ] with value 5 (EAP) in
../data/rfc/rfc4072.txt: Accounting-Request messages. This document specifies one additional
../data/rfc/rfc4072.txt: AVP for accounting messages. One or more Accounting-EAP-Auth-Method
../data/rfc/rfc4072.txt: AVPs (see Section 4.1.5) MAY be included in Accounting-Request
../data/rfc/rfc4072.txt- messages to indicate the EAP method(s) used to authenticate the user.
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt- If the NAS has authenticated the user with a locally implemented EAP
../data/rfc/rfc4072.txt- method, it knows the method used and SHOULD include it in an
../data/rfc/rfc4072.txt: Accounting-EAP-Auth-Method AVP.
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt- If the authentication was done using Diameter-EAP-Request/Answer
../data/rfc/rfc4072.txt- messages, the Diameter server SHOULD include one or more
../data/rfc/rfc4072.txt: Accounting-EAP-Auth-Method AVPs in Diameter-EAP-Answer packets with a
../data/rfc/rfc4072.txt- successful result code. In this case, the NAS SHOULD include these
../data/rfc/rfc4072.txt: AVPs in Accounting-Request messages.
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt-
--
../data/rfc/rfc4072.txt- the user's identity by inserting a User-Name AVP to
../data/rfc/rfc4072.txt- Diameter-EAP-Answer messages that have a Result-Code of
../data/rfc/rfc4072.txt- DIAMETER_SUCCESS. A separate billing identifier or pseudonym MAY be
../data/rfc/rfc4072.txt- used for privacy reasons (see Section 8.5). If the user's identity
../data/rfc/rfc4072.txt- is not available to the NAS, the Session-Id AVP MAY be used for
../data/rfc/rfc4072.txt: accounting and billing; however operationally this could be very
../data/rfc/rfc4072.txt- difficult to manage.
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt-2.8.2. Conflicting AVPs
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt- A Diameter-EAP-Answer message containing an EAP-Payload of type
--
../data/rfc/rfc4072.txt- used, and the commands follow the rules and ABNF defined in [NASREQ].
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt- When the Re-Auth-Request (RAR), Re-Auth-Answer (RAA),
../data/rfc/rfc4072.txt- Session-Termination-Request (STR), Session-Termination-Answer (STA),
../data/rfc/rfc4072.txt- Abort-Session-Request (ASR), Abort-Session-Answer (ASA),
../data/rfc/rfc4072.txt: Accounting-Request (ACR), and Accounting-Answer (ACA) commands are
../data/rfc/rfc4072.txt- used together with the Diameter EAP application, they follow the
../data/rfc/rfc4072.txt: rules in [NASREQ] and [BASE]. The accounting commands use
../data/rfc/rfc4072.txt: Application Identifier value of 3 (Diameter Base Accounting); the
../data/rfc/rfc4072.txt- others use 0 (Diameter Common Messages).
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt-3.1. Diameter-EAP-Request (DER) Command
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt- The Diameter-EAP-Request (DER) command, indicated by the Command-Code
--
../data/rfc/rfc4072.txt- [ EAP-Payload ]
../data/rfc/rfc4072.txt- [ EAP-Reissued-Payload ]
../data/rfc/rfc4072.txt- [ EAP-Master-Session-Key ]
../data/rfc/rfc4072.txt- [ EAP-Key-Name ]
../data/rfc/rfc4072.txt- [ Multi-Round-Time-Out ]
../data/rfc/rfc4072.txt: [ Accounting-EAP-Auth-Method ]
../data/rfc/rfc4072.txt- [ Service-Type ]
../data/rfc/rfc4072.txt- * [ Class ]
../data/rfc/rfc4072.txt- * [ Configuration-Token ]
../data/rfc/rfc4072.txt- [ Acct-Interim-Interval ]
../data/rfc/rfc4072.txt- [ Error-Message ]
--
../data/rfc/rfc4072.txt- Diameter-EAP-Request with a Key-Name AVP with non-empty data MUST
../data/rfc/rfc4072.txt- silently discard the AVP. In addition, the home Diameter server
../data/rfc/rfc4072.txt- SHOULD include this AVP in Diameter-EAP-Response only if an empty
../data/rfc/rfc4072.txt- EAP-Key-Name AVP was present in Diameter-EAP-Request.
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt:4.1.5. Accounting-EAP-Auth-Method AVP
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt: The Accounting-EAP-Auth-Method AVP (AVP Code 465) is of type
../data/rfc/rfc4072.txt- Unsigned64. In case of expanded types [EAP, Section 5.7], this AVP
../data/rfc/rfc4072.txt- contains the value ((Vendor-Id * 2^32) + Vendor-Type).
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt- The use of this AVP is described in Section 2.7.
../data/rfc/rfc4072.txt-
--
../data/rfc/rfc4072.txt- +---------------+
../data/rfc/rfc4072.txt- | Command-Code |
../data/rfc/rfc4072.txt- |-------+-------+
../data/rfc/rfc4072.txt- Attribute Name | DER | DEA |
../data/rfc/rfc4072.txt- ------------------------------------|-------+-------|
../data/rfc/rfc4072.txt: Accounting-EAP-Auth-Method | 0 | 0+ |
../data/rfc/rfc4072.txt- Acct-Interim-Interval [BASE] | 0 | 0-1 |
../data/rfc/rfc4072.txt- Auth-Application-Id [BASE] | 1 | 1 |
../data/rfc/rfc4072.txt- Auth-Grace-Period [BASE] | 0-1 | 0-1 |
../data/rfc/rfc4072.txt- Auth-Request-Type [BASE] | 1 | 1 |
../data/rfc/rfc4072.txt- Auth-Session-State [BASE] | 0-1 | 0-1 |
--
../data/rfc/rfc4072.txt- Session-Timeout [BASE] | 0 | 0-1 |
../data/rfc/rfc4072.txt- State [NASREQ] | 0-1 | 0-1 |
../data/rfc/rfc4072.txt- Tunneling [NASREQ] | 0+ | 0+ |
../data/rfc/rfc4072.txt- User-Name [BASE] | 0-1 | 0-1 |
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt:5.2. Accounting AVP Table
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt- The table in this section is used to represent which AVPs defined in
../data/rfc/rfc4072.txt: this document are to be present in the Accounting messages, as
../data/rfc/rfc4072.txt- defined in [BASE].
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt- +-----------+
../data/rfc/rfc4072.txt- | Command |
../data/rfc/rfc4072.txt- | Code |
../data/rfc/rfc4072.txt- |-----+-----+
../data/rfc/rfc4072.txt- Attribute Name | ACR | ACA |
../data/rfc/rfc4072.txt- ---------------------------------------|-----+-----+
../data/rfc/rfc4072.txt: Accounting-EAP-Auth-Method | 0+ | 0 |
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt-
--
../data/rfc/rfc4072.txt- attributes [RFC2548]. The first up to 32 octets of the key is
../data/rfc/rfc4072.txt- stored into MS-MPPE-Recv-Key, and the next up to 32 octets (if
../data/rfc/rfc4072.txt- present) are stored into MS-MPPE-Send-Key. The encryption of this
../data/rfc/rfc4072.txt- attribute is described in [RFC2548].
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt: o Diameter Accounting-EAP-Auth-Method AVPs, if present, are
../data/rfc/rfc4072.txt- discarded.
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt-
--
../data/rfc/rfc4072.txt- translated to an empty RADIUS EAP-Message attribute.
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt- o The type (or expanded type) field from the EAP-Payload AVP can be
../data/rfc/rfc4072.txt- saved either in a local state table, or encoded in a RADIUS
../data/rfc/rfc4072.txt- Proxy-State attribute. This information is needed to construct an
../data/rfc/rfc4072.txt: Accounting-EAP-Auth-Method AVP for the answer message (see below).
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt- RADIUS Access-Accept/Reject/Challenge to Diameter-EAP-Answer:
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt- o If the RADIUS Access-Challenge message does not contain an
../data/rfc/rfc4072.txt- Error-Cause attribute [RFC3576] with value 202 (decimal), "Invalid
--
../data/rfc/rfc4072.txt- MS-MPPE-Send-Key next), and the concatenated value is stored into
../data/rfc/rfc4072.txt- a Diameter EAP-Master-Session-Key AVP.
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt- o If the Diameter-EAP-Answer will have a successful result code, the
../data/rfc/rfc4072.txt- saved state (see above) can be used to construct an
../data/rfc/rfc4072.txt: Accounting-EAP-Auth-Method AVP.
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt-
--
../data/rfc/rfc4072.txt-Eronen, et al. Standards Track [Page 23]
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt-RFC 4072 Diameter EAP Application August 2005
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt:6.3. Accounting Requests
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt: In Accounting-Requests, the vendor-specific RADIUS MS-Acct-EAP-Type
../data/rfc/rfc4072.txt- attribute [RFC2548] can be translated to a Diameter
../data/rfc/rfc4072.txt: Accounting-EAP-Auth-Method AVP, and vice versa.
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt- When translating from Diameter to RADIUS, note that the
../data/rfc/rfc4072.txt- MS-Acct-EAP-Type attribute does not support expanded EAP types. Type
../data/rfc/rfc4072.txt- values greater than 255 should be translated to type 254.
../data/rfc/rfc4072.txt-
--
../data/rfc/rfc4072.txt- from the AVP Code namespace defined in [BASE] as follows:
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt- 462 for EAP-Payload (defined in Section 4.1.1),
../data/rfc/rfc4072.txt- 463 for EAP-Reissued-Payload (defined in Section 4.1.2),
../data/rfc/rfc4072.txt- 464 for EAP-Master-Session-Key (defined in Section 4.1.3), and
../data/rfc/rfc4072.txt: 465 for Accounting-EAP-Auth-Method (defined in Section 4.1.5).
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt- o This document defines one new AVP (attribute) whose AVP Code
../data/rfc/rfc4072.txt- (Attribute Type) is to be allocated from the Attribute Type
../data/rfc/rfc4072.txt- namespace defined in [RFC2865] and [RFC3575]. The Radius
../data/rfc/rfc4072.txt- Attribute Type for EAP-Key-Name (defined in Section 4.1.4) is 102.
--
../data/rfc/rfc4072.txt- o Modify Calling-Station-ID (either to hide the true value, gain
../data/rfc/rfc4072.txt- access, or frame someone else).
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt- o Modify password change messages (some vendor-specific attributes).
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt: o Modify usage information in accounting messages.
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt- o Modify contents of Class and State AVPs.
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt- Some of these attacks can be prevented if the NAS or server is
../data/rfc/rfc4072.txt- configured to not accept some particular AVPs, or accepts them only
--
../data/rfc/rfc4072.txt- inside EAP-Payload AVPs, and it may be possible to eavesdrop this
../data/rfc/rfc4072.txt- between the user and the NAS.
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt- This can be mitigated somewhat by using EAP methods that provide
../data/rfc/rfc4072.txt- identity protection (see [EAP], Section 7.3), and using Session-Id or
../data/rfc/rfc4072.txt: pseudonyms for accounting.
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt-
../data/rfc/rfc4072.txt-Eronen, et al. Standards Track [Page 28]
../data/rfc/rfc4072.txt-
--
../data/rfc/rfc6440.txt-
../data/rfc/rfc6440.txt-2.2. Acronyms
../data/rfc/rfc6440.txt-
../data/rfc/rfc6440.txt- o FQDN: Fully Qualified Domain Name
../data/rfc/rfc6440.txt-
../data/rfc/rfc6440.txt: o AAA: Authentication, Authorization, and Accounting
../data/rfc/rfc6440.txt-
../data/rfc/rfc6440.txt- o DSRK: Domain-Specific Root Key
../data/rfc/rfc6440.txt-
../data/rfc/rfc6440.txt-3. Option Format
../data/rfc/rfc6440.txt-
--
../data/rfc/rfc4149.txt-
../data/rfc/rfc4149.txt-5.6. RTFM
../data/rfc/rfc4149.txt-
../data/rfc/rfc4149.txt- The Realtime Traffic Flow Measurement (RTFM) working group is
../data/rfc/rfc4149.txt- concerned with issues relating to traffic flow measurements and usage
../data/rfc/rfc4149.txt: reporting for network traffic and Internet accounting. Various
../data/rfc/rfc4149.txt- documents exist that describe requirements [RFC1272], traffic flow
../data/rfc/rfc4149.txt- measurement architectures [RFC2722], and a traffic flow MIB
../data/rfc/rfc4149.txt- [RFC2720]. The work in this group is focused on passive measurements
../data/rfc/rfc4149.txt- of user traffic. As such, its work is related to the monitoring work
../data/rfc/rfc4149.txt- within the RMON WG. Fundamentally, their attention has not been
--
../data/rfc/rfc4149.txt- [RFC4150] Dietz, R. and R. Cole, "Transport Performance Metrics
../data/rfc/rfc4149.txt- MIB", RFC 4150, August 2005.
../data/rfc/rfc4149.txt-
../data/rfc/rfc4149.txt-11. Informative References
../data/rfc/rfc4149.txt-
../data/rfc/rfc4149.txt: [RFC1272] Mills, C., Hirsch, G., and G. Ruth, "Internet Accounting
../data/rfc/rfc4149.txt- Background", RFC 1272, November 1991.
../data/rfc/rfc4149.txt-
../data/rfc/rfc4149.txt- [RFC2021] Waldbusser, S., "Remote Network Monitoring Management
../data/rfc/rfc4149.txt- Information Base Version 2 using SMIv2", RFC 2021,
../data/rfc/rfc4149.txt- January 1997.
--
../data/rfc/rfc2150.txt- what hardware and OS you'll need, there are a great deal of software
../data/rfc/rfc2150.txt- packages available to help you with all sorts of things on the
../data/rfc/rfc2150.txt- computer.
../data/rfc/rfc2150.txt-
../data/rfc/rfc2150.txt- Software designed to make your life easier by using your computer,
../data/rfc/rfc2150.txt: include dictionaries and other reference materials, accounting,
../data/rfc/rfc2150.txt- bookkeeping desktop publishing and other business needs software, as
../data/rfc/rfc2150.txt-
../data/rfc/rfc2150.txt-
../data/rfc/rfc2150.txt-
../data/rfc/rfc2150.txt-
--
../data/rfc/rfc725.txt-such as status or help.
../data/rfc/rfc725.txt-
../data/rfc/rfc725.txt-x2z Connection - Replies referring to the Telnet and data
../data/rfc/rfc725.txt-connections.
../data/rfc/rfc725.txt-
../data/rfc/rfc725.txt:x3z Authentication and accounting - Replies for the logon process
../data/rfc/rfc725.txt-and accountng procedures.
../data/rfc/rfc725.txt-
../data/rfc/rfc725.txt-x4z Unspecified as yet.
../data/rfc/rfc725.txt-
../data/rfc/rfc725.txt-x5z File system - These replies indicate the status of the Server
--
../data/rfc/rfc2809.txt-4.1.1. NAS authentication
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt- With this approach, authentication and authorization (including
../data/rfc/rfc2809.txt- tunneling information) occurs once, at the NAS. The advantages of
../data/rfc/rfc2809.txt- this approach are that it disallows network access for unauthorized
../data/rfc/rfc2809.txt: NAS users, and permits accounting to done at the NAS. Disadvantages
../data/rfc/rfc2809.txt- are that it requires that the tunnel server trust the NAS, since no
../data/rfc/rfc2809.txt- user authentication occurs at the tunnel server. Due to the lack of
../data/rfc/rfc2809.txt: user authentication, accounting cannot take place at the tunnel
../data/rfc/rfc2809.txt- server with strong assurance that the correct party is being billed.
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt- NAS-only authentication is most typically employed along with LCP
../data/rfc/rfc2809.txt- forwarding and tunnel authentication, both of which are supported in
../data/rfc/rfc2809.txt- L2TP, described in [2]. Thus, the tunnel server can be set up to
--
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt- With this approach, authentication and authorization occurs once at
../data/rfc/rfc2809.txt- the NAS and the RADIUS reply is forwarded to the tunnel server. This
../data/rfc/rfc2809.txt- approach disallows network access for unauthorized NAS users; does
../data/rfc/rfc2809.txt- not require trust between the NAS and tunnel server; and allows for
../data/rfc/rfc2809.txt: accounting to be done at both ends of the tunnel. However, it also
../data/rfc/rfc2809.txt- requires that both ends share the same secret with the RADIUS server,
../data/rfc/rfc2809.txt- since that is the only way that the tunnel server can check the
../data/rfc/rfc2809.txt- RADIUS Access-Reply.
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt- In this approach, the tunnel server will share secrets with all the
--
../data/rfc/rfc2809.txt- allows the RADIUS server to authorize users based on the calling
../data/rfc/rfc2809.txt- phone number or to provide tunnel attributes based on the Calling-
../data/rfc/rfc2809.txt- Station-Id or Called-Station-Id. Similarly, in L2TP the tunnel
../data/rfc/rfc2809.txt- server MAY choose to reject or accept the call based on the Dialed
../data/rfc/rfc2809.txt- Number and Dialing Number included in the L2TP Incoming-Call-Request
../data/rfc/rfc2809.txt: packet sent by the NAS. Accounting can also take place based on the
../data/rfc/rfc2809.txt- Calling-Station-Id and Called-Station-Id.
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt- RADIUS as defined in [1] requires that an Access-Request packet
../data/rfc/rfc2809.txt- contain a User-Name attribute as well as either a CHAP-Password or
../data/rfc/rfc2809.txt- User-Password attribute, which must be non-empty. To satisfy this
--
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt- Send data through the tunnel
../data/rfc/rfc2809.txt- Re-negotiate LCP,
../data/rfc/rfc2809.txt- authenticate user,
../data/rfc/rfc2809.txt- bring up IPCP,
../data/rfc/rfc2809.txt: start accounting
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt-
--
../data/rfc/rfc2809.txt- result, this scheme typically uses either the domain portion of the
../data/rfc/rfc2809.txt- userID or attribute-specific processing on the RADIUS server. Since
../data/rfc/rfc2809.txt- the user identity is never verified by the NAS, either the tunnel
../data/rfc/rfc2809.txt- server owner must be willing to be billed for all incoming calls, or
../data/rfc/rfc2809.txt- other information such as the Calling-Station-Id must be used to
../data/rfc/rfc2809.txt: verify the user's identity for accounting purposes.
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt- In attribute-specific processing RADIUS may be employed and an
../data/rfc/rfc2809.txt- attribute is used to signal tunnel initiation. For example, tunnel
../data/rfc/rfc2809.txt- attributes can be sent back if the User-Password attribute contains a
../data/rfc/rfc2809.txt- dummy value (such as "tunnel" or "L2TP"). Alternatively, a userID
--
../data/rfc/rfc2809.txt- Another solution involves using the domain portion of the userID; all
../data/rfc/rfc2809.txt- users in domain X would be tunneled to address Y. This proposal
../data/rfc/rfc2809.txt- supports compulsory tunneling, but does not provide for user-based
../data/rfc/rfc2809.txt- tunneling.
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt: In order for the NAS to start accounting on the connection, it would
../data/rfc/rfc2809.txt- need to use the identity claimed by the user in authenticating to the
../data/rfc/rfc2809.txt- tunnel server, since it did not verify the identity via RADIUS.
../data/rfc/rfc2809.txt: However, in order for that to be of any use in accounting, the tunnel
../data/rfc/rfc2809.txt- endpoint needs to have an account relationship with the NAS owner.
../data/rfc/rfc2809.txt- Thus even if a user has an account with the NAS owner, they cannot
../data/rfc/rfc2809.txt- use this account for tunneling unless the tunnel endpoint also has a
../data/rfc/rfc2809.txt- business relationship with the NAS owner. Thus this approach is
../data/rfc/rfc2809.txt- incompatible with roaming.
--
../data/rfc/rfc2809.txt- client.
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt- In performing the PPP authentication, the tunnel server can access
../data/rfc/rfc2809.txt- its own user database, or it MAY send a RADIUS Access-Request. After
../data/rfc/rfc2809.txt- the tunnel has been brought up, the NAS and tunnel server can start
../data/rfc/rfc2809.txt: accounting.
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt-
--
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt- Send data through the tunnel
../data/rfc/rfc2809.txt- Re-negotiate LCP,
../data/rfc/rfc2809.txt- authenticate user,
../data/rfc/rfc2809.txt- bring up IPCP,
../data/rfc/rfc2809.txt: start accounting
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt-4.2. Dual authentication
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt- In this scheme, authentication occurs both at the NAS and the tunnel
../data/rfc/rfc2809.txt- server. This requires the dial-up client to handle dual
--
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt-RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt- Advantages of dual authentication include support for authentication
../data/rfc/rfc2809.txt: and accounting at both ends of the tunnel; use of a single
../data/rfc/rfc2809.txt- userID/password pair via implementation of RADIUS on the tunnel
../data/rfc/rfc2809.txt- network server; no requirement for telephone-number based
../data/rfc/rfc2809.txt- authentication, or attribute-specific processing on the RADIUS
../data/rfc/rfc2809.txt- server.
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt: Dual authentication allows for accounting records to be generated on
../data/rfc/rfc2809.txt- both the NAS and tunnel server ends, making auditing possible. Also
../data/rfc/rfc2809.txt- the tunnel endpoint does not need to have an account relationship
../data/rfc/rfc2809.txt- with the NAS owner, making this approach compatible with roaming.
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt- A disadvantage of dual authentication is that unless LCP forwarding
--
../data/rfc/rfc2809.txt- forwarding SHOULD NOT be employed.
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt- In performing the PPP authentication, the tunnel server can access
../data/rfc/rfc2809.txt- its own user database, or it MAY send a RADIUS Access-Request. After
../data/rfc/rfc2809.txt- the tunnel has been brought up, the NAS and tunnel server can start
../data/rfc/rfc2809.txt: accounting.
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt- The interactions involved in initiation of a compulsory tunnel with
../data/rfc/rfc2809.txt- dual authentication are summarized below.
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt-
--
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt- Send data through the tunnel
../data/rfc/rfc2809.txt- Re-negotiate LCP,
../data/rfc/rfc2809.txt- authenticate user,
../data/rfc/rfc2809.txt- bring up IPCP,
../data/rfc/rfc2809.txt: start accounting
../data/rfc/rfc2809.txt- ENDIF
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt-
--
../data/rfc/rfc2809.txt- IF user disconnected
../data/rfc/rfc2809.txt- send
../data/rfc/rfc2809.txt- Call-Disconnect-Notify
../data/rfc/rfc2809.txt- message to tunnel server
../data/rfc/rfc2809.txt- Tear down the call
../data/rfc/rfc2809.txt: stop accounting
../data/rfc/rfc2809.txt- ELSE IF client requests
../data/rfc/rfc2809.txt- termination
../data/rfc/rfc2809.txt- send
../data/rfc/rfc2809.txt- Call-Clear-Request
../data/rfc/rfc2809.txt- to the NAS
../data/rfc/rfc2809.txt- Send
../data/rfc/rfc2809.txt- Call-Disconnect-Notify
../data/rfc/rfc2809.txt- message to tunnel server
../data/rfc/rfc2809.txt- Disconnect the user
../data/rfc/rfc2809.txt- Tear down the call
../data/rfc/rfc2809.txt: stop accounting
../data/rfc/rfc2809.txt- ENDIF
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt-6. Use of distinct RADIUS servers
../data/rfc/rfc2809.txt-
../data/rfc/rfc2809.txt- In the case that the NAS and the tunnel server are using distinct
--
../data/rfc/rfc2486.txt-
../data/rfc/rfc2486.txt- [2] Rigney C., Rubens A., Simpson W. and S. Willens, "Remote
../data/rfc/rfc2486.txt- Authentication Dial In User Service (RADIUS)", RFC 2138, April
../data/rfc/rfc2486.txt- 1997.
../data/rfc/rfc2486.txt-
../data/rfc/rfc2486.txt: [3] Rigney C., "RADIUS Accounting", RFC 2139, April 1997.
../data/rfc/rfc2486.txt-
../data/rfc/rfc2486.txt- [4] Mockapetris, P., "Domain Names - Implementation and
../data/rfc/rfc2486.txt- Specification", STD 13, RFC 1035, November 1987.
../data/rfc/rfc2486.txt-
../data/rfc/rfc2486.txt- [5] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
--
../data/rfc/rfc2681.txt-
../data/rfc/rfc2681.txt-
../data/rfc/rfc2681.txt-2.7. Errors and Uncertainties:
../data/rfc/rfc2681.txt-
../data/rfc/rfc2681.txt- The description of any specific measurement method should include an
../data/rfc/rfc2681.txt: accounting and analysis of various sources of error or uncertainty.
../data/rfc/rfc2681.txt- The Framework document provides general guidance on this point, but
../data/rfc/rfc2681.txt- we note here the following specifics related to delay metrics:
../data/rfc/rfc2681.txt-
../data/rfc/rfc2681.txt- + Errors or uncertainties due to uncertainty in the clock of the Src
../data/rfc/rfc2681.txt- host.
--
../data/rfc/rfc2681.txt- + Errors or uncertainties due to time required by the Dst to receive
../data/rfc/rfc2681.txt- the packet from the Src and send the corresponding response.
../data/rfc/rfc2681.txt-
../data/rfc/rfc2681.txt- In addition, the loss threshold may affect the results. Each of
../data/rfc/rfc2681.txt- these are discussed in more detail below, along with a section
../data/rfc/rfc2681.txt: ("Calibration") on accounting for these errors and uncertainties.
../data/rfc/rfc2681.txt-
../data/rfc/rfc2681.txt-2.7.1. Errors or Uncertainties Related to Clocks
../data/rfc/rfc2681.txt-
../data/rfc/rfc2681.txt- The uncertainty in a measurement of round-trip delay is related, in
../data/rfc/rfc2681.txt- part, to uncertainty in the clock of the Src host. In the following,
--
../data/rfc/rfc1331.txt- Implementation Note:
../data/rfc/rfc1331.txt-
../data/rfc/rfc1331.txt- Mark idle (continuous ones) SHOULD NOT be used for idle
../data/rfc/rfc1331.txt- synchronous inter-frame time fill. However, certain types of
../data/rfc/rfc1331.txt- circuit-switched links require the use of mark idle, particularly
../data/rfc/rfc1331.txt: those that calculate accounting based on bit activity. When mark
../data/rfc/rfc1331.txt- idle is used on a synchronous link, the implementation MUST ensure
../data/rfc/rfc1331.txt- at least 15 consecutive "1" bits between Flags, and that the Flag
../data/rfc/rfc1331.txt- Sequence is generated at the beginning and end of a frame.
../data/rfc/rfc1331.txt-
../data/rfc/rfc1331.txt-Flag Sequence
--
../data/rfc/rfc1616.txt- allow providers to offer a better quality of service. There is
../data/rfc/rfc1616.txt- presently ongoing work within the IETF Working Group MADMAN to
../data/rfc/rfc1616.txt- define SNMP monitoring and managing of E-mail systems, gateways
../data/rfc/rfc1616.txt- and X.500 directory systems. A number of management areas that
../data/rfc/rfc1616.txt- need to be worked upon include: QOS, Service Level Agreements
../data/rfc/rfc1616.txt: (SLAs), Multiple system queue management, Accounting, Routing Co-
../data/rfc/rfc1616.txt-
../data/rfc/rfc1616.txt-
../data/rfc/rfc1616.txt-
../data/rfc/rfc1616.txt-RARE WG-MSG Task Force 88 [Page 10]
../data/rfc/rfc1616.txt-
--
../data/rfc/rfc1616.txt- - providing global messaging for all e-mail users, but
../data/rfc/rfc1616.txt- recognising the existing market realities of heterogeneous e-
../data/rfc/rfc1616.txt- mail systems, would be enhanced by the establishment of
../data/rfc/rfc1616.txt- gateways to X.400(1988).
../data/rfc/rfc1616.txt-
../data/rfc/rfc1616.txt: - being able to recover costs by charging and accounting for
../data/rfc/rfc1616.txt- messaging services back to users - this is especially
../data/rfc/rfc1616.txt- important for commercial service providers - is brought about
../data/rfc/rfc1616.txt- by the message auditing capabilities of X.400(1988).
../data/rfc/rfc1616.txt-
../data/rfc/rfc1616.txt- - communication with users that have no access to E-mail (for
--
../data/rfc/rfc7752.txt- 6.1.6. Verifying Correct Operation ........................39
../data/rfc/rfc7752.txt- 6.2. Management Considerations .................................39
../data/rfc/rfc7752.txt- 6.2.1. Management Information .............................39
../data/rfc/rfc7752.txt- 6.2.2. Fault Management ...................................39
../data/rfc/rfc7752.txt- 6.2.3. Configuration Management ...........................40
../data/rfc/rfc7752.txt: 6.2.4. Accounting Management ..............................40
../data/rfc/rfc7752.txt- 6.2.5. Performance Management .............................40
../data/rfc/rfc7752.txt- 6.2.6. Security Management ................................41
../data/rfc/rfc7752.txt- 7. TLV/Sub-TLV Code Points Summary ................................41
../data/rfc/rfc7752.txt- 8. Security Considerations ........................................42
../data/rfc/rfc7752.txt- 9. References .....................................................43
--
../data/rfc/rfc7752.txt-
../data/rfc/rfc7752.txt- An implementation SHOULD allow the operator to configure a pair of
../data/rfc/rfc7752.txt- ASN and BGP-LS identifiers (Section 3.2.1.4) per flooding set in
../data/rfc/rfc7752.txt- which the node participates.
../data/rfc/rfc7752.txt-
../data/rfc/rfc7752.txt:6.2.4. Accounting Management
../data/rfc/rfc7752.txt-
../data/rfc/rfc7752.txt- Not Applicable.
../data/rfc/rfc7752.txt-
../data/rfc/rfc7752.txt-6.2.5. Performance Management
../data/rfc/rfc7752.txt-
--
../data/rfc/rfc5996.txt- included in the two messages following the one containing the EAP
../data/rfc/rfc5996.txt- Success message.
../data/rfc/rfc5996.txt-
../data/rfc/rfc5996.txt- When the initiator authentication uses EAP, it is possible that the
../data/rfc/rfc5996.txt- contents of the IDi payload is used only for Authentication,
../data/rfc/rfc5996.txt: Authorization, and Accounting (AAA) routing purposes and selecting
../data/rfc/rfc5996.txt- which EAP method to use. This value may be different from the
../data/rfc/rfc5996.txt- identity authenticated by the EAP method. It is important that
../data/rfc/rfc5996.txt- policy lookups and access control decisions use the actual
../data/rfc/rfc5996.txt- authenticated identity. Often the EAP server is implemented in a
../data/rfc/rfc5996.txt- separate AAA server that communicates with the IKEv2 responder. In
--
../data/rfc/rfc4331.txt- Server implementations store and account for their data in many
../data/rfc/rfc4331.txt- different ways. Some of the challenges:
../data/rfc/rfc4331.txt-
../data/rfc/rfc4331.txt- o Some server implementations find it prohibitive to count storage
../data/rfc/rfc4331.txt- used for metadata; others may choose to do so for better
../data/rfc/rfc4331.txt: accounting.
../data/rfc/rfc4331.txt-
../data/rfc/rfc4331.txt- o Older versions of resources may be stored as well.
../data/rfc/rfc4331.txt-
../data/rfc/rfc4331.txt- o Variants of one resource may exist with different content lengths.
../data/rfc/rfc4331.txt-
--
../data/rfc/rfc4331.txt- o Resource bodies can be compressed.
../data/rfc/rfc4331.txt-
../data/rfc/rfc4331.txt- o Some resources may be stored for "free", not counting against
../data/rfc/rfc4331.txt- quota.
../data/rfc/rfc4331.txt-
../data/rfc/rfc4331.txt: Since server storage accounting can vary so much, clients should
../data/rfc/rfc4331.txt- expect the following:
../data/rfc/rfc4331.txt-
../data/rfc/rfc4331.txt- o The size of a file on the client's file system, or in a PUT
../data/rfc/rfc4331.txt- message, may not correspond to the amount of storage required by
../data/rfc/rfc4331.txt- the server to store the resource. Thus, the client cannot predict
--
../data/rfc/rfc5850.txt- components include a SIP mixer, recording service, announcement
../data/rfc/rfc5850.txt- server, and voice-dialog server. (This is not an exhaustive
../data/rfc/rfc5850.txt- list).
../data/rfc/rfc5850.txt-
../data/rfc/rfc5850.txt- o Include authentication, authorization, policy, logging, and
../data/rfc/rfc5850.txt: accounting mechanisms to allow these primitives to be used safely
../data/rfc/rfc5850.txt- among mutually untrusted participants. Some of these mechanisms
../data/rfc/rfc5850.txt- may be used to assist in billing, but no specific billing system
../data/rfc/rfc5850.txt- will be endorsed.
../data/rfc/rfc5850.txt-
../data/rfc/rfc5850.txt- o Permit graceful fallback to baseline SIP. Definitions for new SIP
--
../data/rfc/rfc2881.txt- Network Access Server (NAS). The purpose of this effort is to set
../data/rfc/rfc2881.txt- the reference space for describing and evaluating NAS service
../data/rfc/rfc2881.txt- protocols, such as RADIUS (RFCs 2865, 2866) [1], [2] and follow-on
../data/rfc/rfc2881.txt- efforts like AAA Working Group, and the Diameter protocol [3]. These
../data/rfc/rfc2881.txt- are protocols for carrying user service information for
../data/rfc/rfc2881.txt: authentication, authorization, accounting, and auditing, between a
../data/rfc/rfc2881.txt- Network Access Server which desires to authenticate its incoming
../data/rfc/rfc2881.txt- calls and a shared authentication server.
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt-Table of Contents
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt- 1. INTRODUCTION...................................................2
../data/rfc/rfc2881.txt- 1.1 Scope of this Document ......................................2
../data/rfc/rfc2881.txt- 1.2 Specific Terminology ........................................3
../data/rfc/rfc2881.txt- 2. NETWORK ACCESS SYSTEM EQUIPMENT ASSUMPTIONS....................3
../data/rfc/rfc2881.txt- 3. NAS SERVICES...................................................4
../data/rfc/rfc2881.txt: 4. AUTHENTICATION, AUTHORIZATION AND ACCOUNTING (AAA) SERVERS.....5
../data/rfc/rfc2881.txt- 5. TYPICAL NAS OPERATION SEQUENCE:................................5
../data/rfc/rfc2881.txt- 5.1 Characteristics of Systems and Sessions: ....................6
../data/rfc/rfc2881.txt- 5.2 Separation of NAS and AAA server functions ..................7
../data/rfc/rfc2881.txt- 5.3 Network Management and Administrative features ..............7
../data/rfc/rfc2881.txt- 6. AUTHENTICATION METHODS.........................................8
--
../data/rfc/rfc2881.txt- 9.1 A Reference Model of a NAS .................................10
../data/rfc/rfc2881.txt- 9.2 Terminology ................................................11
../data/rfc/rfc2881.txt- 9.3 Analysis ...................................................13
../data/rfc/rfc2881.txt- 9.3.1 Authentication and Security .............................13
../data/rfc/rfc2881.txt- 9.3.2 Authorization and Policy ................................14
../data/rfc/rfc2881.txt: 9.3.3 Accounting and Auditing .................................14
../data/rfc/rfc2881.txt- 9.3.4 Resource Management .....................................14
../data/rfc/rfc2881.txt- 9.3.5 Virtual Private Networks (VPN's) ........................14
../data/rfc/rfc2881.txt- 9.3.6 Service Quality .........................................15
../data/rfc/rfc2881.txt- 9.3.7 Roaming .................................................15
../data/rfc/rfc2881.txt- 10. SECURITY CONSIDERATIONS......................................15
--
../data/rfc/rfc2881.txt-3. NAS Services
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt- The core of what a NAS provides, are dynamic network services. What
../data/rfc/rfc2881.txt- distinguishes a NAS from a typical routing system, is that these
../data/rfc/rfc2881.txt- services are provided on a per-user basis, based on an authentication
../data/rfc/rfc2881.txt: and the service is accounted for. This accounting may lead to
../data/rfc/rfc2881.txt- policies and controls to limit appropriate usage to levels based on
../data/rfc/rfc2881.txt- the availability of network bandwidth, or service agreements between
../data/rfc/rfc2881.txt- the user and the provider.
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt- Typical services include:
--
../data/rfc/rfc2881.txt-Mitton & Beadles Informational [Page 4]
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt-RFC 2881 NASreq NAS Model July 2000
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt:4. Authentication, Authorization and Accounting (AAA) Servers
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt- Because of the need to authenticate and account, and for practical
../data/rfc/rfc2881.txt- reasons of implementation, NAS systems have come to depend on
../data/rfc/rfc2881.txt- external server systems to implement authentication databases and
../data/rfc/rfc2881.txt: accounting recording.
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt- By separating these functions from the NAS equipment, they can be
../data/rfc/rfc2881.txt- implemented in general purpose computer systems, that may provide
../data/rfc/rfc2881.txt- better suited long term storage media, and more sophisticated
../data/rfc/rfc2881.txt- database software infrastructures. Not to mention that a centralized
--
../data/rfc/rfc2881.txt- (such as OS shell login, or Web Server access) from the same
../data/rfc/rfc2881.txt- provider, without creating separate passwords and accounts for the
../data/rfc/rfc2881.txt- user.
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt- Session activity information is stored and processed to produce
../data/rfc/rfc2881.txt: accounting usage records. This is typically done with a long term
../data/rfc/rfc2881.txt- (nightly, weekly or monthly) batch type process.
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt- However, as network operations grow in sophistication, there are
../data/rfc/rfc2881.txt- requirements to provide real-time monitoring of port and user status,
../data/rfc/rfc2881.txt- so that the state information can be used to implement policy
--
../data/rfc/rfc2881.txt- - permanent serial connections (printers)
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt-5.1 Characteristics of Systems and Sessions:
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt- Sessions must have a user identifier and authenticator to complete
../data/rfc/rfc2881.txt: the authentication process. Accounting starts from time of call or
../data/rfc/rfc2881.txt- service, though finer details are allowed. At the end of service, the
../data/rfc/rfc2881.txt- call may be disconnected or allow re-authentication for additional
../data/rfc/rfc2881.txt- services.
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt-
--
../data/rfc/rfc2881.txt- Authorization to run services are supplied and applied after
../data/rfc/rfc2881.txt- authentication. A NAS may abort call if session authorization
../data/rfc/rfc2881.txt- information disagrees with call characteristics. Some system
../data/rfc/rfc2881.txt- resources may be controlled by server driven policies
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt: Accounting messages are sent to the accounting server when service
../data/rfc/rfc2881.txt- begins, and ends, and possibly periodically during service delivery.
../data/rfc/rfc2881.txt: Accounting is not necessarily a real-time service, the NAS may be
../data/rfc/rfc2881.txt- queue and batch send event records.
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt-5.2 Separation of NAS and AAA server functions
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt- As a distributed system, there is a separation of roles between the
--
../data/rfc/rfc2881.txt- - The process of providing a service may lead to requests for
../data/rfc/rfc2881.txt- additional information
../data/rfc/rfc2881.txt- - Service authorization may require real-time enforcement
../data/rfc/rfc2881.txt- (services may be based on Time of Day, or variable cost
../data/rfc/rfc2881.txt- debits)
../data/rfc/rfc2881.txt: - Session accounting information is tallied by the NAS and
../data/rfc/rfc2881.txt- reported to server
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt-5.3 Network Management and Administrative features
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt- The NAS system is presumed to have a method of configuration that
--
../data/rfc/rfc2881.txt- end user, and acts as a gateway for all further services. It is the
../data/rfc/rfc2881.txt- point at which users are authenticated, access policy is enforced,
../data/rfc/rfc2881.txt- network services are authorized, network usage is audited, and
../data/rfc/rfc2881.txt- resource consumption is tracked. That is, a NAS often acts as the
../data/rfc/rfc2881.txt- policy enforcement point for network AAAA (authentication,
../data/rfc/rfc2881.txt: authorization, accounting, and auditing) services. A NAS is
../data/rfc/rfc2881.txt- typically the first place in a network where security measures and
../data/rfc/rfc2881.txt- policy may be implemented.
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt-9.1 A Reference Model of a NAS
../data/rfc/rfc2881.txt-
--
../data/rfc/rfc2881.txt- +---------------+ | +-------------------+
../data/rfc/rfc2881.txt- | Authentication| _/^\_ |Device Provisioning|
../data/rfc/rfc2881.txt- +---------------+ _/ \_ +-------------------+
../data/rfc/rfc2881.txt- | Authorization | _/ \_ |Device Monitoring |
../data/rfc/rfc2881.txt- +---------------+ _/ \_ +-------------------+
../data/rfc/rfc2881.txt: | Accounting | / The \
../data/rfc/rfc2881.txt- +---------------+ \_ Network(s) _/
../data/rfc/rfc2881.txt- | Auditing | \_ _/
../data/rfc/rfc2881.txt- +---------------+ \_ _/
../data/rfc/rfc2881.txt- \_ _/
../data/rfc/rfc2881.txt- \_/
--
../data/rfc/rfc2881.txt- not limited to: IP address filtering, address assignment, route
../data/rfc/rfc2881.txt- assignment, QoS/differential services, bandwidth control/traffic
../data/rfc/rfc2881.txt- management, compulsory tunneling to a specific endpoint, and
../data/rfc/rfc2881.txt- encryption.
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt: Accounting - Accounting refers to the tracking of the consumption of
../data/rfc/rfc2881.txt- NAS resources by users. This information may be used for
../data/rfc/rfc2881.txt- management, planning, billing, or other purposes. Real-time
../data/rfc/rfc2881.txt: accounting refers to accounting information that is delivered
../data/rfc/rfc2881.txt- concurrently with the consumption of the resources. Batch
../data/rfc/rfc2881.txt: accounting refers to accounting information that is saved until it
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt-
--
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt-RFC 2881 NASreq NAS Model July 2000
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt- is delivered at a later time. Typical information that is
../data/rfc/rfc2881.txt: gathered in accounting is the identity of the user, the nature of
../data/rfc/rfc2881.txt- the service delivered, when the service began, and when it ended.
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt- Auditing - Auditing refers to the tracking of activity by users. As
../data/rfc/rfc2881.txt: opposed to accounting, where the purpose is to track consumption
../data/rfc/rfc2881.txt- of resources, the purpose of auditing is to determine the nature
../data/rfc/rfc2881.txt- of a user's network activity. Examples of auditing information
../data/rfc/rfc2881.txt- include the identity of the user, the nature of the services used,
../data/rfc/rfc2881.txt- what hosts were accessed when, what protocols were used, etc.
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt- AAAA Server - An AAAA Server is a server or servers that provide
../data/rfc/rfc2881.txt: authentication, authorization, accounting, and auditing services.
../data/rfc/rfc2881.txt- These may be co-located with the NAS, or more typically, are
../data/rfc/rfc2881.txt- located on a separate server and communicate with the NAS's User
../data/rfc/rfc2881.txt- Management Interface via an AAAA protocol. The four AAAA
../data/rfc/rfc2881.txt- functions may be located on a single server, or may be broken up
../data/rfc/rfc2881.txt- among multiple servers.
--
../data/rfc/rfc2881.txt- Resource management can be performed at a NAS by granting specific
../data/rfc/rfc2881.txt- types of service based on the current network state. In the case of
../data/rfc/rfc2881.txt- shared operation, NAS policy may be determined based on the policy of
../data/rfc/rfc2881.txt- multiple end systems.
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt:9.3.3 Accounting and Auditing
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt- Since NAS services are consumable resources, usage information must
../data/rfc/rfc2881.txt- often be collected for the purposes of soft policy management,
../data/rfc/rfc2881.txt: reporting, planning, and accounting. A dynamic, real-time view of
../data/rfc/rfc2881.txt- NAS usage is often required for network auditing purposes. Since a
../data/rfc/rfc2881.txt- NAS may be shared among multiple administrative entities, usage
../data/rfc/rfc2881.txt- information must often be delivered to multiple endpoints.
../data/rfc/rfc2881.txt: Accounting is performed using such protocols as RADIUS [2].
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt-9.3.4 Resource Management
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt- NAS's deliver resources to users, often in a dynamic fashion.
../data/rfc/rfc2881.txt- Examples of the types of resources doled out by NAS's are IP
--
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt- [1] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
../data/rfc/rfc2881.txt- Authentication Dial In User Service (RADIUS)", RFC 2865, June
../data/rfc/rfc2881.txt- 2000.
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt: [2] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt- [3] Calhoun, P., "Diameter Base Protocol", Work in Progress.
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt- [4] Zorn, G., "Yet Another Authentication Protocol (YAAP)", Work in
../data/rfc/rfc2881.txt- Progress.
--
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt- [9] Zorn, G., Leifer, D., Rubens, A., Shriver, J. and M. Holdrege,
../data/rfc/rfc2881.txt- "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June
../data/rfc/rfc2881.txt- 2000.
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt: [10] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
../data/rfc/rfc2881.txt- Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt- [11] Aboba, B. and G. Zorn, "Implementation of PPTP/L2TP Compulsory
../data/rfc/rfc2881.txt- Tunneling via RADIUS", RFC 2809, April 2000.
../data/rfc/rfc2881.txt-
--
../data/rfc/rfc2881.txt-RFC 2881 NASreq NAS Model July 2000
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt-14. Appendix - Acronyms and Glossary:
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt: AAA - Authentication, Authorization, Accounting, The three primary
../data/rfc/rfc2881.txt- services required by a NAS server or protocol.
../data/rfc/rfc2881.txt-
../data/rfc/rfc2881.txt- NAS - Network Access Server, a system that provides access to a
../data/rfc/rfc2881.txt- network. In some cases also know as a RAS, Remote Access Server.
../data/rfc/rfc2881.txt-
--
../data/rfc/rfc5271.txt-
../data/rfc/rfc5271.txt-4. Network Reference Model for Mobile IPv6 over 3G CDMA Networks
../data/rfc/rfc5271.txt-
../data/rfc/rfc5271.txt- Figure 1 shows a simplified reference model of the Mobile IP enabled
../data/rfc/rfc5271.txt- 3G CDMA networks. The home agent (HA) and Authentication,
../data/rfc/rfc5271.txt: Authorization, and Accounting (AAA) server of the mobile node (MN)
../data/rfc/rfc5271.txt- reside in the home IP network, and the MN roams within or between the
../data/rfc/rfc5271.txt- access provider network(s). Usually, the home IP network is not
../data/rfc/rfc5271.txt- populated by the MNs, which are instead connected only to the access
../data/rfc/rfc5271.txt- provider networks. Prior to the Mobile IPv6 registration, the MN
../data/rfc/rfc5271.txt- establishes a 3G CDMA access technology specific link-layer
--
../data/rfc/rfc4004.txt- Copyright (C) The Internet Society (2005).
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt-Abstract
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt- This document specifies a Diameter application that allows a Diameter
../data/rfc/rfc4004.txt: server to authenticate, authorize and collect accounting information
../data/rfc/rfc4004.txt- for Mobile IPv4 services rendered to a mobile node. Combined with
../data/rfc/rfc4004.txt- the Inter-Realm capability of the base protocol, this application
../data/rfc/rfc4004.txt- allows mobile nodes to receive service from foreign service
../data/rfc/rfc4004.txt: providers. Diameter Accounting messages will be used by the foreign
../data/rfc/rfc4004.txt- and home agents to transfer usage information to the Diameter
../data/rfc/rfc4004.txt- servers.
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt-Table of Contents
../data/rfc/rfc4004.txt-
--
../data/rfc/rfc4004.txt- 9.10. MIP-FA-to-MN-SPI AVP. . . . . . . . . . . . . . . . . . .42
../data/rfc/rfc4004.txt- 9.11. MIP-FA-to-HA-SPI AVP. . . . . . . . . . . . . . . . . . .42
../data/rfc/rfc4004.txt- 9.12. MIP-Nonce AVP. . . . . . . . . . . . . . . . . . .. . . .42
../data/rfc/rfc4004.txt- 9.13. MIP-MSA-Lifetime AVP . . . . . . . . . . . . . . .. . . .42
../data/rfc/rfc4004.txt- 9.14. MIP-HA-to-FA-SPI AVP . . . . . . . . . . . . . . .. . . .43
../data/rfc/rfc4004.txt: 10. Accounting AVPs . . . . . . . . . . . . . . . . . . . . . . . .43
../data/rfc/rfc4004.txt: 10.1. Accounting-Input-Octets AVP . . . . . . . . . . . . . . .43
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt-Calhoun, et al. Standards Track [Page 2]
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt-RFC 4004 Diameter MIP August 2005
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt: 10.2. Accounting-Output-Octets AVP. . . . . . . . . . . . . . .43
../data/rfc/rfc4004.txt- 10.3. Acct-Session-Time AVP . . . . . . . . . . . . . . . . . .43
../data/rfc/rfc4004.txt: 10.4. Accounting-Input-Packets AVP. . . . . . . . . . . . . . .43
../data/rfc/rfc4004.txt: 10.5. Accounting-Output-Packets AVP . . . . . . . . . . . . . .43
../data/rfc/rfc4004.txt- 10.6. Event-Timestamp AVP . . . . . . . . . . . . . . . . . . .44
../data/rfc/rfc4004.txt- 11. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . .44
../data/rfc/rfc4004.txt- 11.1. Mobile IP Command AVP Table . . . . . . . . . . . . . . .44
../data/rfc/rfc4004.txt: 11.2. Accounting AVP Table. . . . . . . . . . . . . . . . . . .46
../data/rfc/rfc4004.txt- 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .46
../data/rfc/rfc4004.txt- 12.1. Command Codes . . . . . . . . . . . . . . . . . . . . . .46
../data/rfc/rfc4004.txt- 12.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . .46
../data/rfc/rfc4004.txt- 12.3. Result-Code AVP Values. . . . . . . . . . . . . . . . . .46
../data/rfc/rfc4004.txt- 12.4. MIP-Feature-Vector AVP Values . . . . . . . . . . . . . .47
--
../data/rfc/rfc4004.txt- authorized to attach and use resources in the foreign domain. Also,
../data/rfc/rfc4004.txt- the FA must provide information to the home administrative domain
../data/rfc/rfc4004.txt- about the resources used by the MN while it is attached in the
../data/rfc/rfc4004.txt- foreign domain.
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt: The Authentication, Authorization, and Accounting (AAA) requirements
../data/rfc/rfc4004.txt- for Mobile IPv4 are described in detail in other documents [MIPREQ,
../data/rfc/rfc4004.txt- CDMA2000]. This document specifies a Diameter application to meet
../data/rfc/rfc4004.txt- these requirements. This application is not applicable to the Mobile
../data/rfc/rfc4004.txt- IPv6 protocol.
../data/rfc/rfc4004.txt-
--
../data/rfc/rfc4004.txt- the MN and FA (MN-FA MSA). If available, the MN-FA MSA is used by
../data/rfc/rfc4004.txt- the FA to authenticate each Registration Request passing through it
../data/rfc/rfc4004.txt- on the way to the HA. Although not critical to the operation of the
../data/rfc/rfc4004.txt- base protocol, the MN-FA MSA is useful when the FA has to know the
../data/rfc/rfc4004.txt- authenticity of a Registration Request; e.g., when it will be
../data/rfc/rfc4004.txt: generating accounting records for a session. The MN-FA MSA may also
../data/rfc/rfc4004.txt- be useful in future work related to handoff optimization.
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt- Similarly, Mobile IPv4 supports an optional MSA between the FA and HA
../data/rfc/rfc4004.txt- (FA-HA MSA). The FA-HA MSA is useful for authenticating messages
../data/rfc/rfc4004.txt- between the FA and HA, such as when the HA seeks to inform the FA
--
../data/rfc/rfc4004.txt- continue the same Mobile IPv4 session by using its existing HA and
../data/rfc/rfc4004.txt- home address.
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt- The MN accomplishes this by sending a Mobile IPv4 Registration
../data/rfc/rfc4004.txt- Request from its new point of attachment. To enable a single set of
../data/rfc/rfc4004.txt: accounting records to be maintained for the entire session, including
../data/rfc/rfc4004.txt- handoffs, it is necessary to allow the AAAH to bind the new
../data/rfc/rfc4004.txt- registration to the pre-existing session. To enable the Mobile IPv4
../data/rfc/rfc4004.txt- Registration Request to be routed to the same AAAH, the MN SHOULD
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt-
--
../data/rfc/rfc4004.txt- defines the relationship of this application to the Diameter Base
../data/rfc/rfc4004.txt- Protocol. Section 5 defines the new command codes. Section 6
../data/rfc/rfc4004.txt- defines the new result codes used by this application. Section 7
../data/rfc/rfc4004.txt- defines the set of mandatory Attribute-Value-Pairs (AVPs). Section 8
../data/rfc/rfc4004.txt- gives an overview of the key distribution capability, and Section 9
../data/rfc/rfc4004.txt: defines the key distribution AVPs. Section 10 defines the accounting
../data/rfc/rfc4004.txt- AVPs, and section 11 contains a listing of all AVPs and their
../data/rfc/rfc4004.txt- occurrence in Diameter commands. Finally, sections 12 and 13 give
../data/rfc/rfc4004.txt- IANA and security considerations, respectively.
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt-2. Acronyms
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt: AAAH Authentication, Authorization, and Accounting Home
../data/rfc/rfc4004.txt: AAAF Authentication, Authorization, and Accounting Foreign
../data/rfc/rfc4004.txt- AMA AA-Mobile-Node-Answer
../data/rfc/rfc4004.txt- AMR AA-Mobile-Node-Request
../data/rfc/rfc4004.txt- ASR Abort-Session-Request
../data/rfc/rfc4004.txt- AVP Attribute Value Pair
../data/rfc/rfc4004.txt- CoA Care-of-Address
--
../data/rfc/rfc4004.txt- and the mobile sends the RRQ, etc.; however, these steps were
../data/rfc/rfc4004.txt- eliminated from Figure 3 to reduce clutter. The redirect server
../data/rfc/rfc4004.txt- eliminates the AAAF and any other Diameter agents from seeing the
../data/rfc/rfc4004.txt- keys as they are transported to the FA and HA. Note that the message
../data/rfc/rfc4004.txt- flows in Figures 3 and 4 apply only to the initial authentication and
../data/rfc/rfc4004.txt: key exchange. Accounting messages would still be sent via Diameter
../data/rfc/rfc4004.txt- agents, not via the direct connection, unless network policies
../data/rfc/rfc4004.txt- dictate otherwise.
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt- A mobile node that supports the AAA NAI extension [AAANAI], which has
../data/rfc/rfc4004.txt- been previously authenticated and authorized, MUST always include the
--
../data/rfc/rfc4004.txt- Application-Id AVP of the Capabilities-Exchange-Request and
../data/rfc/rfc4004.txt- Capabilities-Exchange-Answer commands [DIAMBASE]. The value of two
../data/rfc/rfc4004.txt- (2) MUST be used as the Application-Id in all AMR/AMA and HAR/HAA
../data/rfc/rfc4004.txt- commands. The value of two (2) MUST be used as the Application-Id in
../data/rfc/rfc4004.txt- all ACR/ACA commands, as this application defines new, mandatory AVPs
../data/rfc/rfc4004.txt: for accounting. The value of zero (0) SHOULD be used as the
../data/rfc/rfc4004.txt- Application-Id in all STR/STA and ASR/ASA commands, as these are
../data/rfc/rfc4004.txt- defined in the Diameter base protocol and no additional mandatory
../data/rfc/rfc4004.txt- AVPs for those commands are defined in this document.
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt- Given the nature of Mobile IPv4, re-authentication can only be
--
../data/rfc/rfc4004.txt-Calhoun, et al. Standards Track [Page 21]
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt-RFC 4004 Diameter MIP August 2005
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt: For correlation to occur, accounting records must have some
../data/rfc/rfc4004.txt- commonality across handoffs. Therefore, the home agent MUST send the
../data/rfc/rfc4004.txt- same Acct-Multi-Session-Id AVP value in all HAAs for the mobile's
../data/rfc/rfc4004.txt- session. That is, the HA generates a unique Acct-Multi-Session-Id
../data/rfc/rfc4004.txt- when receiving an HAR for a new session and returns this same value
../data/rfc/rfc4004.txt- in every HAA for the session. This Acct-Multi-Session-Id AVP will be
../data/rfc/rfc4004.txt- returned to the foreign agent by the AAAH in the AMA. Both the
../data/rfc/rfc4004.txt- foreign and home agents MUST include the Acct-Multi-Session-Id in the
../data/rfc/rfc4004.txt: accounting messages, as depicted in Figure 10.
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt-4.1.3. Diameter Session Termination
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt- A foreign and home agent following this specification MAY expect
../data/rfc/rfc4004.txt- their respective Diameter servers to maintain session state
--
../data/rfc/rfc4004.txt- contains the Security Parameter Index the HA and FA use to refer to
../data/rfc/rfc4004.txt- the HA-FA mobility security association. The FA allocates the SPI,
../data/rfc/rfc4004.txt- and it MUST NOT have a value between zero (0) and 255, which is the
../data/rfc/rfc4004.txt- reserved namespace defined in [MOBILEIP].
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt:10. Accounting AVPs
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt:10.1. Accounting-Input-Octets AVP
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt: The Accounting-Input-Octets AVP (AVP Code 363) is of type Unsigned64,
../data/rfc/rfc4004.txt- and contains the number of octets in IP packets received from the
../data/rfc/rfc4004.txt: user. This AVP MUST be included in all Accounting-Request messages
../data/rfc/rfc4004.txt: and MAY be present in the corresponding Accounting-Answer messages as
../data/rfc/rfc4004.txt- well.
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt:10.2. Accounting-Output-Octets AVP
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt: The Accounting-Output-Octets AVP (AVP Code 364) is of type Unsigned64
../data/rfc/rfc4004.txt- and contains the number of octets in IP packets sent to the user.
../data/rfc/rfc4004.txt: This AVP MUST be included in all Accounting-Request messages and MAY
../data/rfc/rfc4004.txt: be present in the corresponding Accounting-Answer messages as well.
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt-10.3. Acct-Session-Time AVP
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt- The Acct-Time AVP (AVP Code 46) is of type Unsigned32 and indicates
../data/rfc/rfc4004.txt- the length of the current session in seconds. This AVP MUST be
../data/rfc/rfc4004.txt: included in all Accounting-Request messages and MAY be present in the
../data/rfc/rfc4004.txt: corresponding Accounting-Answer messages as well.
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt:10.4. Accounting-Input-Packets AVP
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt: The Accounting-Input-Packets (AVP Code 365) is of type Unsigned64 and
../data/rfc/rfc4004.txt- contains the number of IP packets received from the user. This AVP
../data/rfc/rfc4004.txt: MUST be included in all Accounting-Request messages and MAY be
../data/rfc/rfc4004.txt: present in the corresponding Accounting-Answer messages as well.
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt:10.5. Accounting-Output-Packets AVP
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt: The Accounting-Output-Packets (AVP Code 366) is of type Unsigned64
../data/rfc/rfc4004.txt- and contains the number of IP packets sent to the user. This AVP
../data/rfc/rfc4004.txt: MUST be included in all Accounting-Request messages and MAY be
../data/rfc/rfc4004.txt: present in the corresponding Accounting-Answer messages as well.
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt-
--
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt-10.6. Event-Timestamp AVP
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt- The Event-Timestamp (AVP Code 55) is of type Time and MAY be included
../data/rfc/rfc4004.txt: in an Accounting-Request message to record the time at which this
../data/rfc/rfc4004.txt- event occurred on the mobility agent, in seconds since January 1,
../data/rfc/rfc4004.txt- 1970, 00:00 UTC.
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt-11. AVP Occurrence Tables
../data/rfc/rfc4004.txt-
--
../data/rfc/rfc4004.txt-Calhoun, et al. Standards Track [Page 45]
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt-RFC 4004 Diameter MIP August 2005
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt:11.2. Accounting AVP Table
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt- The table in this section is used to represent which AVPs defined in
../data/rfc/rfc4004.txt: this document are to be present in the Accounting messages, as
../data/rfc/rfc4004.txt- defined in [DIAMBASE].
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt- +-------------+
../data/rfc/rfc4004.txt- | Command-Code|
../data/rfc/rfc4004.txt- |------+------+
../data/rfc/rfc4004.txt- Attribute Name | ACR | ACA |
../data/rfc/rfc4004.txt- -------------------------------------|------+------+
../data/rfc/rfc4004.txt: Accounting-Input-Octets | 1 | 0-1 |
../data/rfc/rfc4004.txt: Accounting-Input-Packets | 1 | 0-1 |
../data/rfc/rfc4004.txt: Accounting-Output-Octets | 1 | 0-1 |
../data/rfc/rfc4004.txt: Accounting-Output-Packets | 1 | 0-1 |
../data/rfc/rfc4004.txt- Acct-Multi-Session-Id | 1 | 0-1 |
../data/rfc/rfc4004.txt- Acct-Session-Time | 1 | 0-1 |
../data/rfc/rfc4004.txt- MIP-Feature-Vector | 1 | 0-1 |
../data/rfc/rfc4004.txt- MIP-Home-Agent-Address | 1 | 0-1 |
../data/rfc/rfc4004.txt- MIP-Mobile-Node-Address | 1 | 0-1 |
--
../data/rfc/rfc4004.txt- [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
../data/rfc/rfc4004.txt- Keyed-Hashing for Message Authentication", RFC 2104,
../data/rfc/rfc4004.txt- February 1997.
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt- [MIPKEYS] Perkins, C. and P. Calhoun, "Authentication,
../data/rfc/rfc4004.txt: Authorization, and Accounting (AAA) Registration Keys
../data/rfc/rfc4004.txt- for Mobile IP", RFC 3957, March 2005.
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt- [AAANAI] Johansson, F. and T. Johansson, "Mobile IPv4 Extension
../data/rfc/rfc4004.txt- for Carrying Network Access Identifiers", RFC 3846,
../data/rfc/rfc4004.txt- June 2004.
--
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt-14.2. Informative References
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt- [MIPREQ] Glass, S., Hiller, T., Jacobs, S., and C. Perkins,
../data/rfc/rfc4004.txt- "Mobile IP Authentication, Authorization, and
../data/rfc/rfc4004.txt: Accounting Requirements", RFC 2977, October 2000.
../data/rfc/rfc4004.txt-
../data/rfc/rfc4004.txt- [CDMA2000] Hiller, T., Walsh, P., Chen, X., Munson, M., Dommety,
../data/rfc/rfc4004.txt- G., Sivalingham, S., Lim, B., McCann, P., Shiino, H.,
../data/rfc/rfc4004.txt- Hirschman, B., Manning, S., Hsu, R., Koo, H., Lipford,
../data/rfc/rfc4004.txt- M., Calhoun, P., Lo, C., Jaques, E., Campbell, E., Xu,
--
../data/rfc/rfc7791.txt- The protocol defined in this document does not modify IKEv2.
../data/rfc/rfc7791.txt- Security considerations for cloning an IKE SA are mostly the same as
../data/rfc/rfc7791.txt- those for the base IKEv2 protocol described in [RFC7296].
../data/rfc/rfc7791.txt-
../data/rfc/rfc7791.txt- Cloning an IKE SA allows an initiator to duplicate existing SAs. As
../data/rfc/rfc7791.txt: a result, it may influence any accounting or control mechanisms based
../data/rfc/rfc7791.txt- on a single IKE SA per authentication.
../data/rfc/rfc7791.txt-
../data/rfc/rfc7791.txt- Suppose a system has a limit on the number of IKE SAs it can handle.
../data/rfc/rfc7791.txt- In this case, cloning an IKE SA may provide a way for resource
../data/rfc/rfc7791.txt- exhaustion, as a single end user may populate multiple IKE SAs.
--
../data/rfc/rfc7791.txt- limit the number of cloned IKE SAs.
../data/rfc/rfc7791.txt-
../data/rfc/rfc7791.txt- Suppose the VPN or any other IPsec-based service monitoring is based
../data/rfc/rfc7791.txt- on the liveliness of the first IKE SA. Such a system considers a
../data/rfc/rfc7791.txt- service is accessed or used from the time IKE performs an
../data/rfc/rfc7791.txt: authentication to the time the IKE SA is deleted. Such accounting
../data/rfc/rfc7791.txt- methods were fine as any IKE SA required an authentication exchange.
../data/rfc/rfc7791.txt- As cloning the IKE SA skips the authentication phase, it may make it
../data/rfc/rfc7791.txt- possible to delete the initial IKE SA while the service is being used
../data/rfc/rfc7791.txt: on the cloned IKE SA. Such accounting methods should consider that
../data/rfc/rfc7791.txt- the service is being used from the first IKE SA establishment to
../data/rfc/rfc7791.txt- until the last IKE SA is removed.
../data/rfc/rfc7791.txt-
../data/rfc/rfc7791.txt-
../data/rfc/rfc7791.txt-
--
../data/rfc/rfc7789.txt- Rexford, "Customized BGP Route Selection Using BGP/MPLS
../data/rfc/rfc7789.txt- VPNs", Cisco Systems, Routing Symposium, October 2009,
../data/rfc/rfc7789.txt- <http://inl.info.ucl.ac.be/system/files/
../data/rfc/rfc7789.txt- Cisco_NAG_2009_ns_bgp.pdf>.
../data/rfc/rfc7789.txt-
../data/rfc/rfc7789.txt: [PMACCT] "pmacct project: IP accounting iconoclasm",
../data/rfc/rfc7789.txt- <http://www.pmacct.net>.
../data/rfc/rfc7789.txt-
../data/rfc/rfc7789.txt-
../data/rfc/rfc7789.txt-
../data/rfc/rfc7789.txt-
--
../data/rfc/rfc7574.txt- 11.1.6. Configuration .....................................65
../data/rfc/rfc7574.txt- 11.2. Management Considerations ................................66
../data/rfc/rfc7574.txt- 11.2.1. Management Interoperability and Information .......67
../data/rfc/rfc7574.txt- 11.2.2. Fault Management ..................................67
../data/rfc/rfc7574.txt- 11.2.3. Configuration Management ..........................67
../data/rfc/rfc7574.txt: 11.2.4. Accounting Management .............................68
../data/rfc/rfc7574.txt- 11.2.5. Performance Management ............................68
../data/rfc/rfc7574.txt- 11.2.6. Security Management ...............................68
../data/rfc/rfc7574.txt- 12. Security Considerations .......................................68
../data/rfc/rfc7574.txt- 12.1. Security of the Handshake Procedure ......................68
../data/rfc/rfc7574.txt- 12.1.1. Protection against Attack 1 .......................69
--
../data/rfc/rfc7574.txt-Bakker, et al. Standards Track [Page 67]
../data/rfc/rfc7574.txt-
../data/rfc/rfc7574.txt-RFC 7574 PPSPP July 2015
../data/rfc/rfc7574.txt-
../data/rfc/rfc7574.txt-
../data/rfc/rfc7574.txt:11.2.4. Accounting Management
../data/rfc/rfc7574.txt-
../data/rfc/rfc7574.txt- Content providers may offer PPSPP hosting for different customers and
../data/rfc/rfc7574.txt- will want to bill these customers, for example, based on bandwidth
../data/rfc/rfc7574.txt: usage. This situation is a common accounting scenario, similar to
../data/rfc/rfc7574.txt- billing per virtual server for web servers. PPSPP can therefore
../data/rfc/rfc7574.txt- benefit from general standardization efforts in this area [RFC2975]
../data/rfc/rfc7574.txt- when they come to fruition.
../data/rfc/rfc7574.txt-
../data/rfc/rfc7574.txt-11.2.5. Performance Management
--
../data/rfc/rfc7574.txt- [RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", RFC
../data/rfc/rfc7574.txt- 2790, DOI 10.17487/RFC2790, March 2000,
../data/rfc/rfc7574.txt- <http://www.rfc-editor.org/info/rfc2790>.
../data/rfc/rfc7574.txt-
../data/rfc/rfc7574.txt- [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to
../data/rfc/rfc7574.txt: Accounting Management", RFC 2975, DOI 10.17487/RFC2975,
../data/rfc/rfc7574.txt- October 2000, <http://www.rfc-editor.org/info/rfc2975>.
../data/rfc/rfc7574.txt-
../data/rfc/rfc7574.txt- [RFC3365] Schiller, J., "Strong Security Requirements for Internet
../data/rfc/rfc7574.txt- Engineering Task Force Standard Protocols", BCP 61, RFC
../data/rfc/rfc7574.txt- 3365, DOI 10.17487/RFC3365, August 2002,
--
../data/rfc/rfc7381.txt- more providers, and is actively managed by a network operations
../data/rfc/rfc7381.txt- entity (the "administrator", whether a single person or a department
../data/rfc/rfc7381.txt- of administrators). Administrators generally support an internal
../data/rfc/rfc7381.txt- network, consisting of users' workstations; personal computers;
../data/rfc/rfc7381.txt- mobile devices; other computing devices and related peripherals; a
../data/rfc/rfc7381.txt: server network, consisting of accounting and business application
../data/rfc/rfc7381.txt- servers; and an external network, consisting of Internet-accessible
../data/rfc/rfc7381.txt- services such as web servers, email servers, VPN systems, and
../data/rfc/rfc7381.txt- customer applications. This document is intended as guidance for
../data/rfc/rfc7381.txt- enterprise network architects and administrators in planning their
../data/rfc/rfc7381.txt- IPv6 deployments.
--
../data/rfc/rfc7381.txt- may be more urgent to manage and have visibility on the internal
../data/rfc/rfc7381.txt- traffic. It is important to manage IPv6 for security purposes,
../data/rfc/rfc7381.txt- even in an ostensibly IPv4-only network, as described in
../data/rfc/rfc7381.txt- [RFC7123].
../data/rfc/rfc7381.txt-
../data/rfc/rfc7381.txt: o In many cases, the corporate accounting, payroll, human resource,
../data/rfc/rfc7381.txt- and other internal systems may only need to be reachable from the
../data/rfc/rfc7381.txt- internal network, so they may be a lower priority. As enterprises
../data/rfc/rfc7381.txt- require their vendors to support IPv6, more internal applications
../data/rfc/rfc7381.txt- will support IPv6 by default, and it can be expected that
../data/rfc/rfc7381.txt- eventually new applications will only support IPv6. The
--
../data/rfc/rfc2679.txt- well.}
../data/rfc/rfc2679.txt-
../data/rfc/rfc2679.txt-3.7. Errors and Uncertainties:
../data/rfc/rfc2679.txt-
../data/rfc/rfc2679.txt- The description of any specific measurement method should include an
../data/rfc/rfc2679.txt: accounting and analysis of various sources of error or uncertainty.
../data/rfc/rfc2679.txt- The Framework document provides general guidance on this point, but
../data/rfc/rfc2679.txt- we note here the following specifics related to delay metrics:
../data/rfc/rfc2679.txt-
../data/rfc/rfc2679.txt- + Errors or uncertainties due to uncertainties in the clocks of the
../data/rfc/rfc2679.txt- Src and Dst hosts.
--
../data/rfc/rfc2679.txt- + Errors or uncertainties due to the difference between 'wire time'
../data/rfc/rfc2679.txt- and 'host time'.
../data/rfc/rfc2679.txt-
../data/rfc/rfc2679.txt- In addition, the loss threshold may affect the results. Each of
../data/rfc/rfc2679.txt- these are discussed in more detail below, along with a section
../data/rfc/rfc2679.txt: ("Calibration") on accounting for these errors and uncertainties.
../data/rfc/rfc2679.txt-
../data/rfc/rfc2679.txt-3.7.1. Errors or uncertainties related to Clocks
../data/rfc/rfc2679.txt-
../data/rfc/rfc2679.txt- The uncertainty in a measurement of one-way delay is related, in
../data/rfc/rfc2679.txt- part, to uncertainties in the clocks of the Src and Dst hosts. In
--
../data/rfc/rfc2196.txt- (2) New user accounts (the account RUMPLESTILTSKIN has been
../data/rfc/rfc2196.txt- unexpectedly created), or high activity on a previously
../data/rfc/rfc2196.txt- low usage account.
../data/rfc/rfc2196.txt- (3) New files (usually with novel or strange file names,
../data/rfc/rfc2196.txt- such as data.xx or k or .xx ).
../data/rfc/rfc2196.txt: (4) Accounting discrepancies (in a UNIX system you might
../data/rfc/rfc2196.txt: notice the shrinking of an accounting file called
../data/rfc/rfc2196.txt- /usr/admin/lastlog, something that should make you very
../data/rfc/rfc2196.txt- suspicious that there may be an intruder).
../data/rfc/rfc2196.txt- (5) Changes in file lengths or dates (a user should be
../data/rfc/rfc2196.txt- suspicious if .EXE files in an MS DOS computer have
../data/rfc/rfc2196.txt- unexplainedly grown by over 1800 bytes).
--
../data/rfc/rfc2196.txt- otherwise have intimate knowledge or access to the systems. In all
../data/rfc/rfc2196.txt- cases, the pre-incident preparation will determine what recovery is
../data/rfc/rfc2196.txt- possible.
../data/rfc/rfc2196.txt-
../data/rfc/rfc2196.txt- If the system supports centralized logging (most do), go back over
../data/rfc/rfc2196.txt: the logs and look for abnormalities. If process accounting and
../data/rfc/rfc2196.txt: connect time accounting is enabled, look for patterns of system
../data/rfc/rfc2196.txt- usage. To a lesser extent, disk usage may shed light on the
../data/rfc/rfc2196.txt: incident. Accounting can provide much helpful information in an
../data/rfc/rfc2196.txt- analysis of an incident and subsequent prosecution. Your ability to
../data/rfc/rfc2196.txt- address all aspects of a specific incident strongly depends on the
../data/rfc/rfc2196.txt- success of this analysis.
../data/rfc/rfc2196.txt-
../data/rfc/rfc2196.txt-5.4 Handling an Incident
--
../data/rfc/rfc2196.txt-
../data/rfc/rfc2196.txt- [Foster and Morrision, 1990] T. Forester, and P. Morrison, "Computer
../data/rfc/rfc2196.txt- Ethics: Tales and Ethical Dilemmas in Computing", MIT Press,
../data/rfc/rfc2196.txt- Cambridge, MA, 1990. (192 pages including index.)
../data/rfc/rfc2196.txt-
../data/rfc/rfc2196.txt: [GAO/IMTEX-89-57, 1989] U.S. General Accounting Office, "Computer
../data/rfc/rfc2196.txt- Security - Virus Highlights Need for Improved Internet Management",
../data/rfc/rfc2196.txt: United States General Accounting Office, Washington, DC, 1989.
../data/rfc/rfc2196.txt-
../data/rfc/rfc2196.txt- [Garfinkel and Spafford, 1991] S. Garfinkel, and E. Spafford,
../data/rfc/rfc2196.txt- "Practical Unix Security", O'Reilly & Associates, ISBN 0-937175-72-2,
../data/rfc/rfc2196.txt- May 1991.
../data/rfc/rfc2196.txt-
--
../data/rfc/rfc5296.txt-
../data/rfc/rfc5296.txt- [17] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
../data/rfc/rfc5296.txt- Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
../data/rfc/rfc5296.txt-
../data/rfc/rfc5296.txt- [18] Housley, R. and B. Aboba, "Guidance for Authentication,
../data/rfc/rfc5296.txt: Authorization, and Accounting (AAA) Key Management", BCP 132,
../data/rfc/rfc5296.txt- RFC 4962, July 2007.
../data/rfc/rfc5296.txt-
../data/rfc/rfc5296.txt-
../data/rfc/rfc5296.txt-
../data/rfc/rfc5296.txt-
--
../data/rfc/rfc4017.txt- Authorization
../data/rfc/rfc4017.txt- Requirement: "EAP peer and authenticator authorization must be
../data/rfc/rfc4017.txt- performed."
../data/rfc/rfc4017.txt-
../data/rfc/rfc4017.txt- Authorization issues are discussed in [RFC3748], Sections 1.2 and
../data/rfc/rfc4017.txt: 7.16. Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc4017.txt- protocols such as RADIUS [RFC2865][RFC3579] may be used to enable
../data/rfc/rfc4017.txt- authorization of EAP peers by a central authority. AAA
../data/rfc/rfc4017.txt- authorization issues are discussed in [RFC3579], Sections 2.6.3
../data/rfc/rfc4017.txt- and 4.3.7.
../data/rfc/rfc4017.txt-
--
../data/rfc/rfc1030.txt-
../data/rfc/rfc1030.txt- The best possible datagram rate over the current Wideband
../data/rfc/rfc1030.txt- configuration is 24,054 bits per channel frame, or 3006 bytes every
../data/rfc/rfc1030.txt- 21.22 milliseconds. Since the transmission route begins and ends on
../data/rfc/rfc1030.txt- an Ethernet, the largest amount of data transmissible (after
../data/rfc/rfc1030.txt: accounting for packet header overhead) is 1438 bytes per packet.
../data/rfc/rfc1030.txt- This translates to approximately 2 packets per frame. Since we want
../data/rfc/rfc1030.txt- to avoid overflowing the channel, we should transmit slightly slower
../data/rfc/rfc1030.txt- than the channel frame rate of 21.2 milliseconds. We therefore came
../data/rfc/rfc1030.txt- up with a best possible throughput of 2 1438-byte packets every 22
../data/rfc/rfc1030.txt- milliseconds, or 1.05 megabits per second.
--
../data/rfc/rfc8116.txt- can be "trusted" to behave in a non-destructive way, is naive. With
../data/rfc/rfc8116.txt- deployment in the wider Internet, and a resultant increase in user
../data/rfc/rfc8116.txt- numbers, an increase in attacks and abuses has followed necessitating
../data/rfc/rfc8116.txt- a change in recommended practices. For example, SMTP servers, which
../data/rfc/rfc8116.txt- were initially available for use by everyone on the Internet, require
../data/rfc/rfc8116.txt: authentication and accounting for users today [RFC5068].
../data/rfc/rfc8116.txt-
../data/rfc/rfc8116.txt- As OLSRv2 is often used in wireless environments, it is potentially
../data/rfc/rfc8116.txt- exposed to different kinds of security threats, some of which are of
../data/rfc/rfc8116.txt- greater significance when compared to wired networks. As radio
../data/rfc/rfc8116.txt- signals can be received as well as transmitted by any compatible
--
../data/rfc/rfc499.txt- CAN (CANCEL) (a) On an output channel, CAN causes the rest of
../data/rfc/rfc499.txt- the output in the SYSOUT data set currently being
../data/rfc/rfc499.txt- transmitted to be omitted. Alternatively, may
../data/rfc/rfc499.txt- omit the rest of the SYSOUT data sets for the job
../data/rfc/rfc499.txt- currently being transmitted; however, the
../data/rfc/rfc499.txt: remaining system and accounting messages will be
../data/rfc/rfc499.txt- sent.
../data/rfc/rfc499.txt-
../data/rfc/rfc499.txt- (b) On an input channel, CAN causes RJS to ignore
../data/rfc/rfc499.txt- the job currently being read. However, the
../data/rfc/rfc499.txt- channel is not aborted as a result, and RJS will
--
../data/rfc/rfc6218.txt- allocated from the Cisco vendor space, that can be used to securely
../data/rfc/rfc6218.txt- transfer cryptographic keying material using standard techniques with
../data/rfc/rfc6218.txt- well-understood security properties. In addition, the Message-
../data/rfc/rfc6218.txt- Authentication-Code Attribute may be used to provide strong
../data/rfc/rfc6218.txt- authentication for any RADIUS message, including those used for
../data/rfc/rfc6218.txt: accounting and dynamic authorization.
../data/rfc/rfc6218.txt-
../data/rfc/rfc6218.txt- These attributes were designed to provide stronger protection and
../data/rfc/rfc6218.txt- more flexibility than the currently defined Vendor-Specific
../data/rfc/rfc6218.txt- MS-MPPE-Send-Key and MS-MPPE-Recv-Key Attributes in [RFC2548] and the
../data/rfc/rfc6218.txt- Message-Authenticator Attribute in [RFC3579].
--
../data/rfc/rfc6218.txt-
../data/rfc/rfc6218.txt-
../data/rfc/rfc6218.txt- successful authentication process. The keying material is of a form
../data/rfc/rfc6218.txt- that may be used in virtually any cryptographic algorithm after
../data/rfc/rfc6218.txt- appropriate processing. These attributes may also be used in other
../data/rfc/rfc6218.txt: cases where an Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc6218.txt- server needs to deliver keying material to a network access point.
../data/rfc/rfc6218.txt-
../data/rfc/rfc6218.txt- Discussion of this document may be directed to the authors.
../data/rfc/rfc6218.txt-
../data/rfc/rfc6218.txt-2. Specification of Requirements
--
../data/rfc/rfc6218.txt- differences are detailed below, with the free variable HASH-ALG
../data/rfc/rfc6218.txt- representing the actual algorithm used.
../data/rfc/rfc6218.txt-
../data/rfc/rfc6218.txt- Request Messages
../data/rfc/rfc6218.txt-
../data/rfc/rfc6218.txt: For requests (e.g., CoA-Request [RFC5176], Accounting-
../data/rfc/rfc6218.txt- Request [RFC2866], etc.), the value of the MAC field is a
../data/rfc/rfc6218.txt- hash of the entire packet except the Request Authenticator
../data/rfc/rfc6218.txt- in the header of the RADIUS packet, using a shared secret as
../data/rfc/rfc6218.txt- the key, as follows.
../data/rfc/rfc6218.txt-
--
../data/rfc/rfc6218.txt- secret) to be used exclusively in the generation of the
../data/rfc/rfc6218.txt- Message-Authentication-Code.
../data/rfc/rfc6218.txt-
../data/rfc/rfc6218.txt- Response Messages
../data/rfc/rfc6218.txt-
../data/rfc/rfc6218.txt: For responses (e.g., CoA-ACK [RFC5176], Accounting-Response
../data/rfc/rfc6218.txt- [RFC2866], etc.), the value of the MAC field is a hash of
../data/rfc/rfc6218.txt- the entire packet except the Response Authenticator in the
../data/rfc/rfc6218.txt- header of the RADIUS packet using a shared secret as the
../data/rfc/rfc6218.txt- key, as follows.
../data/rfc/rfc6218.txt-
--
../data/rfc/rfc6218.txt-
../data/rfc/rfc6218.txt- [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
../data/rfc/rfc6218.txt- "Remote Authentication Dial In User Service (RADIUS)",
../data/rfc/rfc6218.txt- RFC 2865, June 2000.
../data/rfc/rfc6218.txt-
../data/rfc/rfc6218.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc6218.txt-
../data/rfc/rfc6218.txt- [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
../data/rfc/rfc6218.txt- M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol
../data/rfc/rfc6218.txt- Support", RFC 2868, June 2000.
../data/rfc/rfc6218.txt-
--
../data/rfc/rfc8577.txt- neighbor on the RSVP-TE tunnel.
../data/rfc/rfc8577.txt-
../data/rfc/rfc8577.txt- Multiple TE link labels MAY be allocated for the TE link to
../data/rfc/rfc8577.txt- accommodate tunnels requesting protection.
../data/rfc/rfc8577.txt-
../data/rfc/rfc8577.txt: Implementations that maintain per-label bandwidth accounting at each
../data/rfc/rfc8577.txt- hop must aggregate the reservations made for all the LSPs using the
../data/rfc/rfc8577.txt- shared TE link label.
../data/rfc/rfc8577.txt-
../data/rfc/rfc8577.txt-4. Segment Routed RSVP-TE Tunnel Setup
../data/rfc/rfc8577.txt-
--
../data/rfc/rfc3575.txt- Attributes). This document creates no new IANA registries, since a
../data/rfc/rfc3575.txt- RADIUS registry was created by [RFC2865].
../data/rfc/rfc3575.txt-
../data/rfc/rfc3575.txt- RADIUS is not intended as a general-purpose protocol, and allocations
../data/rfc/rfc3575.txt- SHOULD NOT be made for purposes unrelated to Authentication,
../data/rfc/rfc3575.txt: Authorization or Accounting.
../data/rfc/rfc3575.txt-
../data/rfc/rfc3575.txt-2.1. Recommended Registration Policies
../data/rfc/rfc3575.txt-
../data/rfc/rfc3575.txt- For registration requests where a Designated Expert should be
../data/rfc/rfc3575.txt- consulted, the responsible IESG area director should appoint the
--
../data/rfc/rfc3575.txt-
../data/rfc/rfc3575.txt- [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and
../data/rfc/rfc3575.txt- Policy Implementation in Roaming", RFC 2607, June
../data/rfc/rfc3575.txt- 1999.
../data/rfc/rfc3575.txt-
../data/rfc/rfc3575.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc3575.txt-
../data/rfc/rfc3575.txt: [RFC2867] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
../data/rfc/rfc3575.txt- Modifications for Tunnel Protocol Support", RFC 2867,
../data/rfc/rfc3575.txt- June 2000.
../data/rfc/rfc3575.txt-
../data/rfc/rfc3575.txt- [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J.,
../data/rfc/rfc3575.txt- Holdrege, M. and I. Goyret, "RADIUS Attributes for
--
../data/rfc/rfc3575.txt- # Message Reference
../data/rfc/rfc3575.txt- ---- ------------------------- ---------
../data/rfc/rfc3575.txt- 1 Access-Request [RFC2865]
../data/rfc/rfc3575.txt- 2 Access-Accept [RFC2865]
../data/rfc/rfc3575.txt- 3 Access-Reject [RFC2865]
../data/rfc/rfc3575.txt: 4 Accounting-Request [RFC2865]
../data/rfc/rfc3575.txt: 5 Accounting-Response [RFC2865]
../data/rfc/rfc3575.txt: 6 Accounting-Status [RFC2882]
../data/rfc/rfc3575.txt: (now Interim Accounting)
../data/rfc/rfc3575.txt- 7 Password-Request [RFC2882]
../data/rfc/rfc3575.txt- 8 Password-Ack [RFC2882]
../data/rfc/rfc3575.txt- 9 Password-Reject [RFC2882]
../data/rfc/rfc3575.txt: 10 Accounting-Message [RFC2882]
../data/rfc/rfc3575.txt- 11 Access-Challenge [RFC2865]
../data/rfc/rfc3575.txt- 12 Status-Server (experimental) [RFC2865]
../data/rfc/rfc3575.txt- 13 Status-Client (experimental) [RFC2865]
../data/rfc/rfc3575.txt- 21 Resource-Free-Request [RFC2882]
../data/rfc/rfc3575.txt- 22 Resource-Free-Response [RFC2882]
--
../data/rfc/rfc1987.txt- record is used to request and return activity information concerning
../data/rfc/rfc1987.txt- a single virtual connection. Each VC is specified by its input port,
../data/rfc/rfc1987.txt- input VPI, and input VCI. These are specified in the Input Port,
../data/rfc/rfc1987.txt- Input VPI, and Input VCI fields of each VC Activity record. Two
../data/rfc/rfc1987.txt- forms of activity detection are supported. If the switch supports per
../data/rfc/rfc1987.txt: VC traffic accounting the current value of the traffic counter for
../data/rfc/rfc1987.txt- each specified VC must be returned. The units of traffic counted are
../data/rfc/rfc1987.txt- not specified but will typically be either cells or frames. The
../data/rfc/rfc1987.txt- controller must compare the traffic counts returned in the message
../data/rfc/rfc1987.txt- with previous values for each of the specified VCs to determine
../data/rfc/rfc1987.txt- whether each VC has been active in the intervening period. If the
../data/rfc/rfc1987.txt: switch does not support per VC traffic accounting, but is capable of
../data/rfc/rfc1987.txt- detecting per-VC activity by some other unspecified means, the result
../data/rfc/rfc1987.txt-
../data/rfc/rfc1987.txt-
../data/rfc/rfc1987.txt-
../data/rfc/rfc1987.txt-Newman, et. al. Informational [Page 20]
--
../data/rfc/rfc7680.txt- more detail elsewhere; we encourage others to do so as well.}
../data/rfc/rfc7680.txt-
../data/rfc/rfc7680.txt-2.7. Errors and Uncertainties
../data/rfc/rfc7680.txt-
../data/rfc/rfc7680.txt- The description of any specific measurement method should include an
../data/rfc/rfc7680.txt: accounting and analysis of various sources of error or uncertainty.
../data/rfc/rfc7680.txt- The Framework document provides general guidance on this point.
../data/rfc/rfc7680.txt-
../data/rfc/rfc7680.txt- For loss, there are three sources of error:
../data/rfc/rfc7680.txt-
../data/rfc/rfc7680.txt- o synchronization between clocks on Src and Dst.
--
../data/rfc/rfc8466.txt-
../data/rfc/rfc8466.txt- A typical usage for this model is as an input to an orchestration
../data/rfc/rfc8466.txt- layer that is responsible for translating it into configuration
../data/rfc/rfc8466.txt- commands for the network elements that deliver/enable the service.
../data/rfc/rfc8466.txt- The network elements may be routers, but also servers (like
../data/rfc/rfc8466.txt: Authentication, Authorization, and Accounting (AAA)) that are
../data/rfc/rfc8466.txt- necessary within the network.
../data/rfc/rfc8466.txt-
../data/rfc/rfc8466.txt- The configuration of network elements may be done using the Command
../data/rfc/rfc8466.txt- Line Interface (CLI) or any other configuration (or "southbound")
../data/rfc/rfc8466.txt- interface such as NETCONF [RFC6241] in combination with device-
--
../data/rfc/rfc8597.txt-
../data/rfc/rfc8597.txt- Additionally, the following acronyms are used in this document:
../data/rfc/rfc8597.txt-
../data/rfc/rfc8597.txt- CLAS: Cooperating Layered Architecture for SDN
../data/rfc/rfc8597.txt-
../data/rfc/rfc8597.txt: FCAPS: Fault, Configuration, Accounting, Performance, and Security
../data/rfc/rfc8597.txt-
../data/rfc/rfc8597.txt- SDN: Software-Defined Networking
../data/rfc/rfc8597.txt-
../data/rfc/rfc8597.txt- SLA: Service Level Agreement
../data/rfc/rfc8597.txt-
--
../data/rfc/rfc8597.txt- certain path.
../data/rfc/rfc8597.txt-
../data/rfc/rfc8597.txt- o Orchestration: the ability to combine diverse resources (e.g., IT
../data/rfc/rfc8597.txt- and network resources) in an optimal way.
../data/rfc/rfc8597.txt-
../data/rfc/rfc8597.txt: o Accounting: record of resource usage.
../data/rfc/rfc8597.txt-
../data/rfc/rfc8597.txt- o Security: secure communication among components, preventing, for
../data/rfc/rfc8597.txt- example, DoS attacks.
../data/rfc/rfc8597.txt-
../data/rfc/rfc8597.txt-5. Communication between SDN Controllers
--
../data/rfc/rfc8597.txt- o Security: As reflected before, the communication between strata
../data/rfc/rfc8597.txt- must be secure to prevent attacks and threats. Additionally,
../data/rfc/rfc8597.txt- privacy should be enforced, especially when addressing multi-
../data/rfc/rfc8597.txt- provider scenarios at the transport level.
../data/rfc/rfc8597.txt-
../data/rfc/rfc8597.txt: o Accounting: The control and accountancy of resources used and
../data/rfc/rfc8597.txt- consumed by services should be supported in the communication
../data/rfc/rfc8597.txt- among strata.
../data/rfc/rfc8597.txt-
../data/rfc/rfc8597.txt-9. IANA Considerations
../data/rfc/rfc8597.txt-
--
../data/rfc/rfc2705.txt- Call identifiers are expected to be unique within the system, or at a
../data/rfc/rfc2705.txt- minimum, unique within the collection of Call Agents that control the
../data/rfc/rfc2705.txt- same gateways. When a Call Agent builds several connections that
../data/rfc/rfc2705.txt- pertain to the same call, either on the same gateway or in different
../data/rfc/rfc2705.txt- gateways, these connections that belong to the same call share the
../data/rfc/rfc2705.txt: same call-id. This identifier can then be used by accounting or
../data/rfc/rfc2705.txt- management procedures, which are outside the scope of MGCP.
../data/rfc/rfc2705.txt-
../data/rfc/rfc2705.txt-2.1.3.2. Names of connections
../data/rfc/rfc2705.txt-
../data/rfc/rfc2705.txt- Connection identifiers are created by the gateway when it is
--
../data/rfc/rfc2705.txt- "view" of a connection.
../data/rfc/rfc2705.txt-
../data/rfc/rfc2705.txt- CallId is a globally unique parameter that identifies the call (or
../data/rfc/rfc2705.txt- session) to which this connection belongs. Connections that belong to
../data/rfc/rfc2705.txt- the same call share the same call-id. The call-id can be used to
../data/rfc/rfc2705.txt: identify calls for reporting and accounting purposes. It does not
../data/rfc/rfc2705.txt- affect the handling of connections by the gateway.
../data/rfc/rfc2705.txt-
../data/rfc/rfc2705.txt- EndpointId is the identifier for the connection endpoint in the
../data/rfc/rfc2705.txt- gateway where CreateConnection executes. The EndpointId can be
../data/rfc/rfc2705.txt- fully-specified by assigning a value to the parameter EndpointId in
--
../data/rfc/rfc6271.txt- of scope of this document. They include information about SIP
../data/rfc/rfc6271.txt- protocol support (e.g., SIP extensions and field conventions), media
../data/rfc/rfc6271.txt- (e.g., type of media traffic to be exchanged, compatible media codecs
../data/rfc/rfc6271.txt- and transport protocols, mechanisms to ensure differentiated quality
../data/rfc/rfc6271.txt- of service for media), Layer 3 IP connectivity between the signaling
../data/rfc/rfc6271.txt: and data path border elements, and accounting and traffic capacity
../data/rfc/rfc6271.txt- control (e.g., the maximum number of SIP sessions at each ingress
../data/rfc/rfc6271.txt- point, or the maximum number of concurrent IM or VoIP sessions).
../data/rfc/rfc6271.txt-
../data/rfc/rfc6271.txt- The informative Appendix A lists parameters that may be considered
../data/rfc/rfc6271.txt- when discussing the technical parameters of SIP session peering. The
--
../data/rfc/rfc6271.txt- [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
../data/rfc/rfc6271.txt- Protocol Extended Reports (RTCP XR)", RFC 3611,
../data/rfc/rfc6271.txt- November 2003.
../data/rfc/rfc6271.txt-
../data/rfc/rfc6271.txt- [RFC3702] Loughney, J. and G. Camarillo, "Authentication,
../data/rfc/rfc6271.txt: Authorization, and Accounting Requirements for the
../data/rfc/rfc6271.txt- Session Initiation Protocol (SIP)", RFC 3702,
../data/rfc/rfc6271.txt- February 2004.
../data/rfc/rfc6271.txt-
../data/rfc/rfc6271.txt- [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E.,
../data/rfc/rfc6271.txt- and K. Norrman, "The Secure Real-time Transport
--
../data/rfc/rfc6271.txt-
../data/rfc/rfc6271.txt- Various types of policy information may need to be discovered or
../data/rfc/rfc6271.txt- exchanged in order to establish session peering. At a minimum, a
../data/rfc/rfc6271.txt- policy should specify information related to session establishment
../data/rfc/rfc6271.txt- data in order to avoid session establishment failures. A policy may
../data/rfc/rfc6271.txt: also include information related to QoS, billing and accounting, and
../data/rfc/rfc6271.txt- Layer 3 related interconnect requirements, which are out of the scope
../data/rfc/rfc6271.txt- of this document.
../data/rfc/rfc6271.txt-
../data/rfc/rfc6271.txt- Some aspects of session peering policies must be agreed to and
../data/rfc/rfc6271.txt- manually implemented; they are static and are typically documented as
--
../data/rfc/rfc6271.txt-Mule Informational [Page 20]
../data/rfc/rfc6271.txt-
../data/rfc/rfc6271.txt-RFC 6271 SIP Session Peering Requirements June 2011
../data/rfc/rfc6271.txt-
../data/rfc/rfc6271.txt-
../data/rfc/rfc6271.txt: o Accounting:
../data/rfc/rfc6271.txt-
../data/rfc/rfc6271.txt: Methods used for call or session accounting should be specified.
../data/rfc/rfc6271.txt- An SSP may require a peer to track session usage. It is critical
../data/rfc/rfc6271.txt- for peers to determine whether the support of any SIP extensions
../data/rfc/rfc6271.txt: for accounting is a pre-requisite for SIP interoperability. In
../data/rfc/rfc6271.txt: some cases, call accounting may feed data for billing purposes,
../data/rfc/rfc6271.txt: but not always: some operators may decide to use accounting as a
../data/rfc/rfc6271.txt- 'bill and keep' model to track session usage and monitor usage
../data/rfc/rfc6271.txt- against service level agreements.
../data/rfc/rfc6271.txt-
../data/rfc/rfc6271.txt- [RFC3702] defines the terminology and basic requirements for
../data/rfc/rfc6271.txt: accounting of SIP sessions. A few private SIP extensions have
../data/rfc/rfc6271.txt- also been defined and used over the years to enable call
../data/rfc/rfc6271.txt: accounting between SSP domains such as the P-Charging* headers in
../data/rfc/rfc6271.txt- [RFC3455], the P-DCS-Billing-Info header in [RFC5503], etc.
../data/rfc/rfc6271.txt-
../data/rfc/rfc6271.txt- o Performance Metrics:
../data/rfc/rfc6271.txt-
../data/rfc/rfc6271.txt- Layer 5 performance metrics should be defined and shared between
--
../data/rfc/rfc6271.txt- * headers and header values
../data/rfc/rfc6271.txt-
../data/rfc/rfc6271.txt- * possibly, list of SIP RFCs supported by groups (e.g., by call
../data/rfc/rfc6271.txt- feature)
../data/rfc/rfc6271.txt-
../data/rfc/rfc6271.txt: o Accounting
../data/rfc/rfc6271.txt-
../data/rfc/rfc6271.txt- o Capacity Control and Performance Management: any limits on, or,
../data/rfc/rfc6271.txt- means to measure and limit the maximum number of active calls to a
../data/rfc/rfc6271.txt- peer or federation, maximum number of sessions and messages per
../data/rfc/rfc6271.txt- specified unit time, maximum number of active users or subscribers
--
../data/rfc/rfc755.txt- 1 1 Reserved
../data/rfc/rfc755.txt- 2-71 2-107 AHHP Regular Messages [1,3]
../data/rfc/rfc755.txt- 72-151 110-227 Reserved
../data/rfc/rfc755.txt- 152 230 PARC Universal Protocol
../data/rfc/rfc755.txt- 153 231 TIP Status Reporting
../data/rfc/rfc755.txt: 154 232 TIP Accounting
../data/rfc/rfc755.txt- 155-158 233-236 Internet Protocol [35,36,42,43,44]
../data/rfc/rfc755.txt- 159-191 237-277 Measurements [28]
../data/rfc/rfc755.txt- 192-195 300-303 Message Switching Protocol [4,5]
../data/rfc/rfc755.txt- 196-255 304-377 Experimental Protocols
../data/rfc/rfc755.txt- 224-255 340-377 NVP [1,39]
--
../data/rfc/rfc3570.txt- 2.2. Brokering Content Network................................3
../data/rfc/rfc3570.txt- 2.3. Local Request-Routing Content Network....................4
../data/rfc/rfc3570.txt- 3. Content Internetworking Arrangements...........................5
../data/rfc/rfc3570.txt- 4. Content Internetworking Scenarios..............................5
../data/rfc/rfc3570.txt- 4.1. General Content Internetworking..........................6
../data/rfc/rfc3570.txt: 4.2. BCN providing ACCOUNTING INTERNETWORKING and
../data/rfc/rfc3570.txt- REQUEST-ROUTING INTERNETWORKING..........................9
../data/rfc/rfc3570.txt: 4.3. BCN providing ACCOUNTING INTERNETWORKING................11
../data/rfc/rfc3570.txt- 4.4. PCN ENLISTS multiple CNs................................12
../data/rfc/rfc3570.txt- 4.5. Multiple CNs ENLIST LCN.................................13
../data/rfc/rfc3570.txt- 5. Security Considerations.......................................15
../data/rfc/rfc3570.txt- 5.1. Threats to Content Internetworking......................15
../data/rfc/rfc3570.txt- 5.1.1. Threats to the CLIENT.............................15
--
../data/rfc/rfc3570.txt-RFC 3570 CDI Scenarios July 2003
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-2. Special Cases of Content Networks
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt: A CN may have REQUEST-ROUTING, DISTRIBUTION, and ACCOUNTING
../data/rfc/rfc3570.txt- interfaces. However, some participating networks may gravitate
../data/rfc/rfc3570.txt- toward particular subsets of the CONTENT INTERNETWORKING interfaces.
../data/rfc/rfc3570.txt- Others may be seen differently in terms of how they relate to their
../data/rfc/rfc3570.txt- CLIENT bases. This section describes these refined cases of the
../data/rfc/rfc3570.txt- general CN case so they may be available for easier reference in the
--
../data/rfc/rfc3570.txt- ENLISTED CNs. Second, it implies that the PCN need only participate
../data/rfc/rfc3570.txt- in a subset of CONTENT INTERNETWORKING. For example, a PCN's
../data/rfc/rfc3570.txt- DISTRIBUTION INTERNETWORKING SYSTEM need only be able to receive
../data/rfc/rfc3570.txt- DISTRIBUTION ADVERTISEMENTS, it need not send them. Similarly, a
../data/rfc/rfc3570.txt- PCN's REQUEST-ROUTING INTERNETWORKING SYSTEM has no reason to send
../data/rfc/rfc3570.txt: AREA ADVERTISEMENTS. Finally, a PCN's ACCOUNTING INTERNETWORKING
../data/rfc/rfc3570.txt: SYSTEM need only be able to receive ACCOUNTING data, it need not send
../data/rfc/rfc3570.txt- it.
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-2.2. Brokering Content Network
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt- A Brokering Content Network (BCN) is a network that does not operate
--
../data/rfc/rfc3570.txt-Rzewski, et al. Informational [Page 3]
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-RFC 3570 CDI Scenarios July 2003
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt: ACCOUNTING INTERNETWORKING in order to aggregate utilization data
../data/rfc/rfc3570.txt- from several CNs into combined reports for CNs that represent
../data/rfc/rfc3570.txt- PUBLISHERS.
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt- This definition of a BCN implies that a BCN's CIGs would implement
../data/rfc/rfc3570.txt- the sending and/or receiving of any combination of ADVERTISEMENTS and
../data/rfc/rfc3570.txt: ACCOUNTING data as is necessary to provide desired services to other
../data/rfc/rfc3570.txt- CONTENT NETWORKS. For example, if a BCN is only interested in
../data/rfc/rfc3570.txt: aggregating ACCOUNTING data on behalf of other CNs, it would only
../data/rfc/rfc3570.txt: need to have an ACCOUNTING INTERNETWORKING interface on its CIGs.
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-2.3. Local Request-Routing Content Network
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt- Another type of CN is the Local Request-Routing CONTENT NETWORK
../data/rfc/rfc3570.txt- (LCN). An LCN is defined as a type of network where CLIENTS' CONTENT
--
../data/rfc/rfc3570.txt- particular item of CONTENT. By directing CONTENT REQUESTS through
../data/rfc/rfc3570.txt- the local SERVER, CONTENT RESPONSES may be given to CLIENTS without
../data/rfc/rfc3570.txt- first referring to the AUTHORITATIVE REQUEST-ROUTING SYSTEM. Knowing
../data/rfc/rfc3570.txt- this to be true, other CNs may seek a NEGOTIATED RELATIONSHIP with an
../data/rfc/rfc3570.txt- LCN in order to perform DISTRIBUTION into the LCN and receive
../data/rfc/rfc3570.txt: ACCOUNTING data from it. Note that once SERVERS participate in
../data/rfc/rfc3570.txt: DISTRIBUTION INTERNETWORKING and ACCOUNTING INTERNETWORKING, they
../data/rfc/rfc3570.txt- effectively take on the role of SURROGATES. However, an LCN would
../data/rfc/rfc3570.txt- not intend to allow its SURROGATES to be accessed by non-local
../data/rfc/rfc3570.txt- CLIENTS.
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt- This set of assumptions implies multiple things about the LCN's
../data/rfc/rfc3570.txt- CONTENT INTERNETWORKING relationships. First, it is implied that the
../data/rfc/rfc3570.txt- LCN's DISTRIBUTION INTERNETWORKING SYSTEM need only be able to send
../data/rfc/rfc3570.txt- DISTRIBUTION ADVERTISEMENTS, it need not receive them. Second, it is
../data/rfc/rfc3570.txt: implied that an LCN's ACCOUNTING INTERNETWORKING SYSTEM need only be
../data/rfc/rfc3570.txt: able to send ACCOUNTING data, it need not receive it. Finally, due
../data/rfc/rfc3570.txt- to the locally defined REQUEST-ROUTING, the LCN would not participate
../data/rfc/rfc3570.txt- in REQUEST-ROUTING INTERNETWORKING.
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-
--
../data/rfc/rfc3570.txt- technical terms (such as SLAs).
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt- In the event that the controlling interests of two CNs no longer wish
../data/rfc/rfc3570.txt- to have their networks interconnected, it is expected that these
../data/rfc/rfc3570.txt- tasks would be undone. That is, the protocol configurations would be
../data/rfc/rfc3570.txt: changed to cease the movement of ADVERTISEMENTS and/or ACCOUNTING
../data/rfc/rfc3570.txt- data between the networks, and the NEGOTIATED RELATIONSHIP would be
../data/rfc/rfc3570.txt- legally terminated.
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-4. Content Internetworking Scenarios
../data/rfc/rfc3570.txt-
--
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt- This scenario considers the general case where two or more existing
../data/rfc/rfc3570.txt- CNs wish to establish a CONTENT INTERNETWORKING relationship in order
../data/rfc/rfc3570.txt- to provide increased scale and reach for their existing customers.
../data/rfc/rfc3570.txt- It assumes that all of these CNs already provide REQUEST-ROUTING,
../data/rfc/rfc3570.txt: DISTRIBUTION, and ACCOUNTING services and that they will continue to
../data/rfc/rfc3570.txt- provide these services to existing customers as well as offering them
../data/rfc/rfc3570.txt- to other CNs.
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt- In this scenario, these CNs would interconnect with others via a CIG
../data/rfc/rfc3570.txt- that provides a REQUEST-ROUTING INTERNETWORKING SYSTEM, a
../data/rfc/rfc3570.txt: DISTRIBUTION INTERNETWORKING SYSTEM, and an ACCOUNTING
../data/rfc/rfc3570.txt- INTERNETWORKING SYSTEM. The net result of this interconnection would
../data/rfc/rfc3570.txt- be that a larger set of SURROGATES will now be available to the
../data/rfc/rfc3570.txt- CLIENTS.
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt- Figure 1 shows three CNs which have interconnected to provide greater
../data/rfc/rfc3570.txt- scale and reach to their existing customers. They are all
../data/rfc/rfc3570.txt- participating in DISTRIBUTION INTERNETWORKING, REQUEST-ROUTING
../data/rfc/rfc3570.txt: INTERNETWORKING, and ACCOUNTING INTERNETWORKING.
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt- As a result of the NEGOTIATED RELATIONSHIPS it is assumed that:
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt- 1. CONTENT that has been INJECTED into any one of these ORIGINATING
../data/rfc/rfc3570.txt- CNs may be distributed into any other ENLISTED CN.
--
../data/rfc/rfc3570.txt- within the ORIGINATING CN, or may also be issued within the
../data/rfc/rfc3570.txt- ENLISTED CN. The latter case allows local decisions to be made
../data/rfc/rfc3570.txt- about DISTRIBUTION within the ENLISTED CN, but such commands would
../data/rfc/rfc3570.txt- not control DISTRIBUTION within the ORIGINATING CN.
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt: 3. ACCOUNTING information regarding CLIENT access and/or DISTRIBUTION
../data/rfc/rfc3570.txt- actions will be made available to the ORIGINATING CN by the
../data/rfc/rfc3570.txt- ENLISTED CN.
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-
--
../data/rfc/rfc3570.txt-Rzewski, et al. Informational [Page 6]
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-RFC 3570 CDI Scenarios July 2003
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt: 4. The ORIGINATING CN would provide this ACCOUNTING information to
../data/rfc/rfc3570.txt- the PUBLISHER based on existing Service Level Agreements (SLAs).
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt- 5. CONTENT REQUESTS by CLIENTS may be directed to SURROGATES within
../data/rfc/rfc3570.txt- any of the ENLISTED CNs.
../data/rfc/rfc3570.txt-
--
../data/rfc/rfc3570.txt- |..............| +---------+ +---------+ |..............+
../data/rfc/rfc3570.txt- | REQ-ROUTING |<=>| |<=>| |<=>| REQ-ROUTING |
../data/rfc/rfc3570.txt- |..............| | CONTENT | | CONTENT | |..............|
../data/rfc/rfc3570.txt- | DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION |
../data/rfc/rfc3570.txt- |..............| | GATEWAY | | GATEWAY | |..............|
../data/rfc/rfc3570.txt: | ACCOUNTING |<=>| |<=>| |<=>| ACCOUNTING |
../data/rfc/rfc3570.txt- +--------------+ +---------+ +---------+ +--------------+
../data/rfc/rfc3570.txt- | ^ \^ \ \ ^/ ^/ ^/ | ^
../data/rfc/rfc3570.txt- v | \\ \\ \\ // // // v |
../data/rfc/rfc3570.txt- +--------------+ \\ \\ \\ // // // +--------------+
../data/rfc/rfc3570.txt- | SURROGATES | \\ v\ v\ /v /v // | SURROGATES |
--
../data/rfc/rfc3570.txt- | | |..............| | |
../data/rfc/rfc3570.txt- | | | REQ-ROUTING | | |
../data/rfc/rfc3570.txt- | | |..............| | |
../data/rfc/rfc3570.txt- \ \ | DISTRIBUTION | / /
../data/rfc/rfc3570.txt- \ \ |..............| / /
../data/rfc/rfc3570.txt: \ \ | ACCOUNTING | / /
../data/rfc/rfc3570.txt- \ \ |--------------| / /
../data/rfc/rfc3570.txt- \ \ | ^ / /
../data/rfc/rfc3570.txt- \ \ v | / /
../data/rfc/rfc3570.txt- \ \ +--------------+ / /
../data/rfc/rfc3570.txt- \ \ | SURROGATES | / /
--
../data/rfc/rfc3570.txt-Rzewski, et al. Informational [Page 8]
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-RFC 3570 CDI Scenarios July 2003
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt:4.2. BCN providing ACCOUNTING INTERNETWORKING and REQUEST-ROUTING
../data/rfc/rfc3570.txt- INTERNETWORKING
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt- This scenario describes the case where a single entity (BCN A)
../data/rfc/rfc3570.txt: performs ACCOUNTING INTERNETWORKING and REQUEST-ROUTING
../data/rfc/rfc3570.txt- INTERNETWORKING functions, but has no inherent DISTRIBUTION or
../data/rfc/rfc3570.txt- DELIVERY capabilities. A potential configuration which illustrates
../data/rfc/rfc3570.txt- this concept is given in Figure 2.
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt- In the scenario shown in Figure 2, BCN A is responsible for
../data/rfc/rfc3570.txt: collecting ACCOUNTING information from multiple CONTENT NETWORKS (CN
../data/rfc/rfc3570.txt- A and CN B) to provide a clearinghouse/settlement function, as well
../data/rfc/rfc3570.txt- as providing a REQUEST-ROUTING service for CN A and CN B.
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt- In this scenario, CONTENT is injected into either CN A or CN B and
../data/rfc/rfc3570.txt- its DISTRIBUTION between these CNs is controlled via the DISTRIBUTION
../data/rfc/rfc3570.txt- INTERNETWORKING SYSTEMS within the CIGs. The REQUEST-ROUTING SYSTEM
../data/rfc/rfc3570.txt- provided by BCN A is informed of the ability to serve a piece of
../data/rfc/rfc3570.txt- CONTENT from a particular CONTENT NETWORK by the REQUEST-ROUTING
../data/rfc/rfc3570.txt- SYSTEMS within the interconnected CIGs.
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt: BCN A collects statistics and usage information via the ACCOUNTING
../data/rfc/rfc3570.txt- INTERNETWORKING SYSTEM and disseminates that information to CN A and
../data/rfc/rfc3570.txt- CN B as appropriate.
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt- As illustrated in Figure 2, there are separate REQUEST-ROUTING
../data/rfc/rfc3570.txt- SYSTEMS employed within CN A and CN B. If the REQUEST-ROUTING SYSTEM
--
../data/rfc/rfc3570.txt-Rzewski, et al. Informational [Page 9]
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-RFC 3570 CDI Scenarios July 2003
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt: Figure 2 - BCN providing ACCOUNTING INTERNETWORKING and
../data/rfc/rfc3570.txt- REQUEST-ROUTING INTERNETWORKING
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt- +--------------+
../data/rfc/rfc3570.txt- | BCN A |
../data/rfc/rfc3570.txt- |..............| +-----------+
../data/rfc/rfc3570.txt- | REQ-ROUTING |<===>| |
../data/rfc/rfc3570.txt- |..............| | CONTENT |
../data/rfc/rfc3570.txt: | ACCOUNTING |<===>| INTWRKING |
../data/rfc/rfc3570.txt- +--------------+ | GATEWAY |
../data/rfc/rfc3570.txt- | |
../data/rfc/rfc3570.txt- +-----------+
../data/rfc/rfc3570.txt- ^| ^| ^| ^|
../data/rfc/rfc3570.txt- +--------------+ // // \\ \\ +--------------+
--
../data/rfc/rfc3570.txt- |..............| +---------+ +---------+ |..............|
../data/rfc/rfc3570.txt- | REQ-ROUTING |<=>| | | |<=>| REQ-ROUTING |
../data/rfc/rfc3570.txt- |..............| | CONTENT | | CONTENT | |..............|
../data/rfc/rfc3570.txt- | DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION |
../data/rfc/rfc3570.txt- |..............| | GATEWAY | | GATEWAY | |..............|
../data/rfc/rfc3570.txt: | ACCOUNTING |<=>| | | |<=>| ACCOUNTING |
../data/rfc/rfc3570.txt- +--------------+ +---------+ +---------+ +--------------+
../data/rfc/rfc3570.txt- | ^ | ^
../data/rfc/rfc3570.txt- v | v |
../data/rfc/rfc3570.txt- +--------------+ +--------------+
../data/rfc/rfc3570.txt- | SURROGATES | | SURROGATES |
--
../data/rfc/rfc3570.txt-Rzewski, et al. Informational [Page 10]
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-RFC 3570 CDI Scenarios July 2003
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt:4.3. BCN providing ACCOUNTING INTERNETWORKING
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt- This scenario describes the case where a single entity (BCN A)
../data/rfc/rfc3570.txt: performs ACCOUNTING INTERNETWORKING to provide a clearinghouse/
../data/rfc/rfc3570.txt- settlement function only. In this scenario, BCN A would enter into
../data/rfc/rfc3570.txt- NEGOTIATED RELATIONSHIPS with multiple CNs that each perform their
../data/rfc/rfc3570.txt- own DISTRIBUTION INTERNETOWRKING and REQUEST-ROUTING INTERNETWORKING
../data/rfc/rfc3570.txt- as shown in FIGURE 3.
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt: Figure 3 - BCN providing ACCOUNTING INTERNETWORKING
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt- +--------------+
../data/rfc/rfc3570.txt- | BCN A |
../data/rfc/rfc3570.txt- |..............| +-----------+
../data/rfc/rfc3570.txt: | ACCOUNTING |<===>| |
../data/rfc/rfc3570.txt- +--------------+ | CONTENT |
../data/rfc/rfc3570.txt- | INTWRKING |
../data/rfc/rfc3570.txt- | GATEWAY |
../data/rfc/rfc3570.txt- | |
../data/rfc/rfc3570.txt- +-----------+
--
../data/rfc/rfc3570.txt- |..............| +---------+ +---------+ |..............|
../data/rfc/rfc3570.txt- | REQ-ROUTING |<=>| |<=>| |<=>| REQ-ROUTING |
../data/rfc/rfc3570.txt- |..............| | CONTENT | | CONTENT | |..............|
../data/rfc/rfc3570.txt- | DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION |
../data/rfc/rfc3570.txt- |..............| | GATEWAY | | GATEWAY | |..............|
../data/rfc/rfc3570.txt: | ACCOUNTING |<=>| | | |<=>| ACCOUNTING |
../data/rfc/rfc3570.txt- +--------------+ +---------+ +---------+ +--------------+
../data/rfc/rfc3570.txt- | ^ | ^
../data/rfc/rfc3570.txt- v | v |
../data/rfc/rfc3570.txt- +--------------+ +--------------+
../data/rfc/rfc3570.txt- | SURROGATES | | SURROGATES |
--
../data/rfc/rfc3570.txt- In the previously enumerated scenarios, PUBLISHERS have not been
../data/rfc/rfc3570.txt- discussed. Much of the time, it is assumed that the PUBLISHERS will
../data/rfc/rfc3570.txt- allow CNs to act on their behalf. For example, a PUBLISHER may
../data/rfc/rfc3570.txt- designate a particular CN to be the AUTHORITATIVE REQUEST-ROUTING
../data/rfc/rfc3570.txt- SYSTEM for its CONTENT. Similarly, a PUBLISHER may rely on a
../data/rfc/rfc3570.txt: particular CN to aggregate all its ACCOUNTING data, even though that
../data/rfc/rfc3570.txt- data may originate at SURROGATES in multiple distant CNs. Finally, a
../data/rfc/rfc3570.txt- PUBLISHER may INJECT content only into a single CN and rely on that
../data/rfc/rfc3570.txt- CN to ENLIST other CNs to obtain scale and reach.
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt- However, a PUBLISHER may wish to maintain more control and take on
../data/rfc/rfc3570.txt- the task of ENLISTING CNs itself, therefore acting as a PCN (Section
../data/rfc/rfc3570.txt- 2.1). This scenario, shown in Figure 4, describes the case where a
../data/rfc/rfc3570.txt- PCN wishes to directly enter into NEGOTIATED RELATIONSHIPS with
../data/rfc/rfc3570.txt- multiple CNs. In this scenario, the PCN would operate its own CIG
../data/rfc/rfc3570.txt: and enter into DISTRIBUTION INTERNETWORKING, ACCOUNTING
../data/rfc/rfc3570.txt- INTERNETWORKING, and REQUEST-ROUTING INTERNETWORKING relationships
../data/rfc/rfc3570.txt- with two or more CNs.
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-
--
../data/rfc/rfc3570.txt- |..............| +-----------+
../data/rfc/rfc3570.txt- | REQ-ROUTING |<=>| |<---\
../data/rfc/rfc3570.txt- |..............| | CONTENT |----\\
../data/rfc/rfc3570.txt- | DISTRIBUTION |<=>| INTWRKING | \\
../data/rfc/rfc3570.txt- |..............| | GATEWAY |--\ \\
../data/rfc/rfc3570.txt: | ACCOUNTING |<=>| |<-\\ \\
../data/rfc/rfc3570.txt- +--------------+ +-----------+ \\ \\
../data/rfc/rfc3570.txt- ^| ^| ^| ^| \\ ||
../data/rfc/rfc3570.txt- +--------------+ || || || \\ || || +--------------+
../data/rfc/rfc3570.txt- | CN A | |v |v |v \v |v |v | CN B |
../data/rfc/rfc3570.txt- |..............| +---------+ +---------+ |..............|
../data/rfc/rfc3570.txt- | REQ-ROUTING |<=>| | | |<=>| REQ-ROUTING |
../data/rfc/rfc3570.txt- |..............| | CONTENT | | CONTENT | |..............|
../data/rfc/rfc3570.txt- | DISTRIBUTION |<=>|INTWRKING| |INTWRKING|<=>| DISTRIBUTION |
../data/rfc/rfc3570.txt- |..............| | GATEWAY | | GATEWAY | |..............|
../data/rfc/rfc3570.txt: | ACCOUNTING |<=>| | | |<=>| ACCOUNTING |
../data/rfc/rfc3570.txt- +--------------+ +---------+ +---------+ +--------------+
../data/rfc/rfc3570.txt- | ^ | ^
../data/rfc/rfc3570.txt- v | v |
../data/rfc/rfc3570.txt- +--------------+ +--------------+
../data/rfc/rfc3570.txt- | SURROGATES | | SURROGATES |
--
../data/rfc/rfc3570.txt- has determined that all CONTENT REQUESTS from CLIENTS must be
../data/rfc/rfc3570.txt- serviced locally. Likely due to a large CLIENT base in the LCN,
../data/rfc/rfc3570.txt- multiple CNs determine they would like to engage in DISTRIBUTION
../data/rfc/rfc3570.txt- INTERNETWORKING with the LCN in order to extend control over CONTENT
../data/rfc/rfc3570.txt- objects held in the LCN's SURROGATES. Similarly, the CNs would like
../data/rfc/rfc3570.txt: to engage in ACCOUNTING INTERNETWORKING with the LCN in order to
../data/rfc/rfc3570.txt: receive ACCOUNTING data regarding the usage of the content in the
../data/rfc/rfc3570.txt- local SURROGATES. This scenario is shown in Figure 5. Although this
../data/rfc/rfc3570.txt- diagram shows a DISTRIBUTION INTERNETWORKING connection between CN A
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-
--
../data/rfc/rfc3570.txt- +..............| +---------+ +---------+ |..............+
../data/rfc/rfc3570.txt- | REQ-ROUTING |<=>| |<=>| |<=>| REQ-ROUTING |
../data/rfc/rfc3570.txt- |..............| | CONTENT | | CONTENT | |..............|
../data/rfc/rfc3570.txt- | DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION |
../data/rfc/rfc3570.txt- |..............| | GATEWAY | | GATEWAY | |..............|
../data/rfc/rfc3570.txt: | ACCOUNTING |<=>| |<=>| |<=>| ACCOUNTING |
../data/rfc/rfc3570.txt- +--------------+ +---------+ +---------+ +--------------+
../data/rfc/rfc3570.txt- | ^ \^ \^ ^/ ^/ | ^
../data/rfc/rfc3570.txt- v | \\ \\ // // v |
../data/rfc/rfc3570.txt- +--------------+ \\ \\ // // +--------------+
../data/rfc/rfc3570.txt- | SURROGATES | v\ v\ /v /v | SURROGATES |
--
../data/rfc/rfc3570.txt- +--------------+
../data/rfc/rfc3570.txt- | LCN A |
../data/rfc/rfc3570.txt- |..............|
../data/rfc/rfc3570.txt- | DISTRIBUTION |
../data/rfc/rfc3570.txt- |..............|
../data/rfc/rfc3570.txt: | ACCOUNTING |
../data/rfc/rfc3570.txt- |--------------|
../data/rfc/rfc3570.txt- | ^
../data/rfc/rfc3570.txt- v |
../data/rfc/rfc3570.txt- +--------------+
../data/rfc/rfc3570.txt- | SURROGATES |
--
../data/rfc/rfc3570.txt- Security concerns with respect to Content Internetworking can be
../data/rfc/rfc3570.txt- generally categorized into trust within the system and protection of
../data/rfc/rfc3570.txt- the system from threats. The trust model utilized with Content
../data/rfc/rfc3570.txt- Internetworking is predicated largely on transitive trust between the
../data/rfc/rfc3570.txt- ORIGIN, REQUEST-ROUTING INTERNETWORKING SYSTEM, DISTRIBUTION
../data/rfc/rfc3570.txt: INTERNETWORKING SYSTEM, ACCOUNTING INTERNETWORING SYSTEM, and
../data/rfc/rfc3570.txt- SURROGATES. Network elements within the Content Internetworking
../data/rfc/rfc3570.txt- system are considered to be "insiders" and therefore trusted.
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-5.1. Threats to Content Internetworking
../data/rfc/rfc3570.txt-
--
../data/rfc/rfc3570.txt- expecting for that CONTENT. (Note that this threat differs, at least
../data/rfc/rfc3570.txt- in degree, from the substitution of security parameters threat below,
../data/rfc/rfc3570.txt- as Web Content Zones can control whether or not, for example, the
../data/rfc/rfc3570.txt- browser executes unsigned active content.)
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt:5.1.1.2. Delivery of Bad Accounting Information
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt- In the case of CONTENT with value, CLIENTs may be inappropriately
../data/rfc/rfc3570.txt- charged for viewing content that they did not successfully access.
../data/rfc/rfc3570.txt- Conversely, some PUBLISHERs may reward CLIENTs for viewing certain
../data/rfc/rfc3570.txt-
--
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-RFC 3570 CDI Scenarios July 2003
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt- CONTENT (e.g., programs that "pay" users to surf the Web). Should a
../data/rfc/rfc3570.txt: CN fail to deliver appropriate accounting information, the CLIENT may
../data/rfc/rfc3570.txt- not receive appropriate credit for viewing the required CONTENT.
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-5.1.1.3. Delivery of Bad CONTENT
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt- A CN that does not deliver the appropriate CONTENT may provide the
--
../data/rfc/rfc3570.txt-RFC 3570 CDI Scenarios July 2003
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-5.1.2. Threats to the PUBLISHER
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt:5.1.2.1. Delivery of Bad Accounting Information
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt: If a CN does not deliver accurate accounting information, the
../data/rfc/rfc3570.txt- PUBLISHER may be unable to charge CLIENTs for accessing CONTENT or it
../data/rfc/rfc3570.txt: may reward CLIENTs inappropriately. Inaccurate accounting
../data/rfc/rfc3570.txt- information may also cause a PUBLISHER to pay for services (e.g.,
../data/rfc/rfc3570.txt- content distribution) that were not actually rendered. Invalid
../data/rfc/rfc3570.txt: accounting information may also effect PUBLISHERs indirectly by, for
../data/rfc/rfc3570.txt- example, undercounting the number of site visitors (and, thus,
../data/rfc/rfc3570.txt- reducing the PUBLISHER's advertising revenue).
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-5.1.2.2. Denial of Service
../data/rfc/rfc3570.txt-
--
../data/rfc/rfc3570.txt- ORIGIN, should, for example, legal differences between the
../data/rfc/rfc3570.txt- jurisdictions require or permit different treatment of the CONTENT.
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-5.1.3. Threats to a CN
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt:5.1.3.1. Bad Accounting Information
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt: If a CN is unable to collect or receive accurate accounting
../data/rfc/rfc3570.txt- information, it may be unable to collect compensation for its
../data/rfc/rfc3570.txt- services from PUBLISHERs.
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-
--
../data/rfc/rfc3570.txt-5.1.3.2. Denial of Service
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt- Misuse of a CN may make that CN's facilities unavailable, or
../data/rfc/rfc3570.txt- available only at reduced functionality, to legitimate customers or
../data/rfc/rfc3570.txt- the CN provider itself. Denial of service attacks can be targeted at
../data/rfc/rfc3570.txt: a CN's ACCOUNTING SYSTEM, DISTRIBUTION SYSTEM, or REQUEST-ROUTING
../data/rfc/rfc3570.txt- SYSTEM.
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt-5.1.3.3. Transitive Threats
../data/rfc/rfc3570.txt-
../data/rfc/rfc3570.txt- To the extent that a CN acts as either a CLIENT or a PUBLISHER (such
--
../data/rfc/rfc4176.txt- 2. Customer Service Operations and Management ................... 7
../data/rfc/rfc4176.txt- 2.1. Customer Service Management Information Model .......... 7
../data/rfc/rfc4176.txt- 2.2. Customer Management Functions .......................... 8
../data/rfc/rfc4176.txt- 2.2.1. Fault Management ............................... 8
../data/rfc/rfc4176.txt- 2.2.2. Configuration Management ....................... 9
../data/rfc/rfc4176.txt: 2.2.3. Accounting ..................................... 9
../data/rfc/rfc4176.txt- 2.2.4. Performance Management ......................... 10
../data/rfc/rfc4176.txt- 2.2.5. Security Management ............................ 10
../data/rfc/rfc4176.txt- 2.3. Customer Management Functional Description ............. 11
../data/rfc/rfc4176.txt- 2.3.1. L3VPN Service Offering Management .............. 11
../data/rfc/rfc4176.txt- 2.3.2. L3VPN Service Order Management ................. 12
--
../data/rfc/rfc4176.txt- 3. Provider Network Manager ..................................... 12
../data/rfc/rfc4176.txt- 3.1. Provider Network Management Definition ................. 12
../data/rfc/rfc4176.txt- 3.2. Network Management Functions ........................... 13
../data/rfc/rfc4176.txt- 3.2.1. Fault Management ............................... 13
../data/rfc/rfc4176.txt- 3.2.2. Configuration Management ....................... 14
../data/rfc/rfc4176.txt: 3.2.3. Accounting ..................................... 17
../data/rfc/rfc4176.txt- 3.2.4. Performance Management ......................... 17
../data/rfc/rfc4176.txt- 3.2.5. Security Management ............................ 17
../data/rfc/rfc4176.txt- 4. L3VPN Devices ................................................ 18
../data/rfc/rfc4176.txt- 4.1. Information Model ...................................... 18
../data/rfc/rfc4176.txt- 4.2. Communication .......................................... 18
--
../data/rfc/rfc4176.txt- activated at the egress of the service provider's network.
../data/rfc/rfc4176.txt-
../data/rfc/rfc4176.txt-2.2. Customer Management Functions
../data/rfc/rfc4176.txt-
../data/rfc/rfc4176.txt- This section presents detailed customer management functions in the
../data/rfc/rfc4176.txt: traditional fault, configuration, accounting, performance, and
../data/rfc/rfc4176.txt- security (FCAPS) management categories.
../data/rfc/rfc4176.txt-
../data/rfc/rfc4176.txt-2.2.1. Fault Management
../data/rfc/rfc4176.txt-
../data/rfc/rfc4176.txt- The fault management function of the Customer Service Manager relies
--
../data/rfc/rfc4176.txt- fields such as the customer premises that need to be interconnected
../data/rfc/rfc4176.txt- via the VPN, and a QoS agreement template would contain fields such
../data/rfc/rfc4176.txt- as one-way transit delay, inter-packet delay variation, throughput,
../data/rfc/rfc4176.txt- and packet loss thresholds.
../data/rfc/rfc4176.txt-
../data/rfc/rfc4176.txt:2.2.3. Accounting
../data/rfc/rfc4176.txt-
../data/rfc/rfc4176.txt: The accounting management function of the Customer Manager is
../data/rfc/rfc4176.txt- provided with network layer measurements information and manages this
../data/rfc/rfc4176.txt- information. The Customer Manager is responsible for the following
../data/rfc/rfc4176.txt: accounting functions:
../data/rfc/rfc4176.txt-
../data/rfc/rfc4176.txt: o Retrieval of accounting information from the Provider Network
../data/rfc/rfc4176.txt- Manager
../data/rfc/rfc4176.txt-
../data/rfc/rfc4176.txt- o Analysis, storage, and administration of measurements
../data/rfc/rfc4176.txt-
../data/rfc/rfc4176.txt- Some providers may require near-real time reporting of measurement
--
../data/rfc/rfc4176.txt- management service.
../data/rfc/rfc4176.txt-
../data/rfc/rfc4176.txt- If an SP supports "Dynamic Bandwidth Management" service, then the
../data/rfc/rfc4176.txt- schedule and the amount of the bandwidth required to perform
../data/rfc/rfc4176.txt- requested bandwidth allocation change(s) must be traceable for
../data/rfc/rfc4176.txt: monitoring and accounting purposes.
../data/rfc/rfc4176.txt-
../data/rfc/rfc4176.txt: Solutions should state compliance with accounting requirements, as
../data/rfc/rfc4176.txt- described in section 1.7 of [RFC2975].
../data/rfc/rfc4176.txt-
../data/rfc/rfc4176.txt-
../data/rfc/rfc4176.txt-
../data/rfc/rfc4176.txt-
--
../data/rfc/rfc4176.txt-2.2.4. Performance Management
../data/rfc/rfc4176.txt-
../data/rfc/rfc4176.txt- From the Customer Manager's perspective, performance management
../data/rfc/rfc4176.txt- includes functions involved in the determination of the conformance
../data/rfc/rfc4176.txt- level with the Service Level Specifications, such as QoS and
../data/rfc/rfc4176.txt: availability measurements. The objective is to correlate accounting
../data/rfc/rfc4176.txt- information with performance and fault management information to
../data/rfc/rfc4176.txt- produce billing that takes into account SLA provisions for periods of
../data/rfc/rfc4176.txt- time where the service level objectives are not met.
../data/rfc/rfc4176.txt-
../data/rfc/rfc4176.txt- The performance information should reflect the quality of the
--
../data/rfc/rfc4176.txt- service, the number and size of virtual switching and forwarding
../data/rfc/rfc4176.txt- table instances should be provisioned.
../data/rfc/rfc4176.txt-
../data/rfc/rfc4176.txt- If an SP supports a "Dynamic Bandwidth Management" service, then the
../data/rfc/rfc4176.txt- dates, times, amounts, and intervals required to perform requested
../data/rfc/rfc4176.txt: bandwidth allocation change(s) may be traceable for accounting
../data/rfc/rfc4176.txt- purposes.
../data/rfc/rfc4176.txt-
../data/rfc/rfc4176.txt-
../data/rfc/rfc4176.txt-
../data/rfc/rfc4176.txt-
--
../data/rfc/rfc4176.txt-3.2.2.6. Provisioning Hybrid VPN Services
../data/rfc/rfc4176.txt-
../data/rfc/rfc4176.txt- Configuration of interworking L3VPN solutions should also be
../data/rfc/rfc4176.txt- supported, taking security and end-to-end QoS issues into account.
../data/rfc/rfc4176.txt-
../data/rfc/rfc4176.txt:3.2.3. Accounting
../data/rfc/rfc4176.txt-
../data/rfc/rfc4176.txt- The Provider Network Manager is responsible for the measurements of
../data/rfc/rfc4176.txt- resource utilization.
../data/rfc/rfc4176.txt-
../data/rfc/rfc4176.txt-3.2.4. Performance Management
--
../data/rfc/rfc4176.txt- and their valuable suggestions.
../data/rfc/rfc4176.txt-
../data/rfc/rfc4176.txt-7. Normative References
../data/rfc/rfc4176.txt-
../data/rfc/rfc4176.txt- [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to
../data/rfc/rfc4176.txt: Accounting Management", RFC 2975, October 2000.
../data/rfc/rfc4176.txt-
../data/rfc/rfc4176.txt- [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
../data/rfc/rfc4176.txt- Internet Protocol", RFC 2401, November 1998.
../data/rfc/rfc4176.txt-
../data/rfc/rfc4176.txt- [RFC2903] de Laat, C., Gross, G., Gommans, L., Vollbrecht, J., and
--
../data/rfc/rfc6572.txt- Furthermore, this document defines the RADIUS-based interface between
../data/rfc/rfc6572.txt- the local mobility anchor and the AAA RADIUS server for authorizing
../data/rfc/rfc6572.txt- received Proxy Binding Update messages for the mobile node's mobility
../data/rfc/rfc6572.txt- session. In addition to the interactions related to mobility session
../data/rfc/rfc6572.txt- setup, this document defines the baseline for the mobile access
../data/rfc/rfc6572.txt: gateway and the local mobility anchor generated accounting.
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt-Status of This Memo
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt- This is an Internet Standards Track document.
../data/rfc/rfc6572.txt-
--
../data/rfc/rfc6572.txt- 5.1. Interface Operations ......................................26
../data/rfc/rfc6572.txt- 5.2. Table of Attributes .......................................27
../data/rfc/rfc6572.txt- 6. LMA to RADIUS AAA Interface ....................................28
../data/rfc/rfc6572.txt- 6.1. Interface Operations ......................................28
../data/rfc/rfc6572.txt- 6.2. Table of Attributes .......................................30
../data/rfc/rfc6572.txt: 7. Accounting .....................................................31
../data/rfc/rfc6572.txt: 7.1. Accounting at LMA .........................................31
../data/rfc/rfc6572.txt: 7.2. Accounting at MAG .........................................32
../data/rfc/rfc6572.txt- 7.3. Table of Attributes .......................................32
../data/rfc/rfc6572.txt- 8. Security Considerations ........................................32
../data/rfc/rfc6572.txt- 9. IANA Consideration .............................................33
../data/rfc/rfc6572.txt- 9.1. Attribute Type Codes ......................................33
../data/rfc/rfc6572.txt- 9.2. Namespaces ................................................33
--
../data/rfc/rfc6572.txt- the messaging interface needed between them for the operation of
../data/rfc/rfc6572.txt- PMIP6 is beyond the scope of this document.
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt- Home AAA (HAAA):
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt: An Authentication, Authorization, and Accounting (AAA) server
../data/rfc/rfc6572.txt- located in the MN's home network. This sever has access to the
../data/rfc/rfc6572.txt- mobile node's policy profiles.
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt- Visited AAA (VAAA):
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt: An Authentication, Authorization, and Accounting (AAA) server
../data/rfc/rfc6572.txt- located in the MN's visited network. The VAAA server takes the
../data/rfc/rfc6572.txt- role of a proxy-server, forwarding the received AAA service
../data/rfc/rfc6572.txt- request to the HAAA server in the mobile node's home network and
../data/rfc/rfc6572.txt- relaying the response to the requesting node, after applying any
../data/rfc/rfc6572.txt- local access network policies.
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt- Local AAA (LAAA):
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt: An Authentication, Authorization, and Accounting proxy located in
../data/rfc/rfc6572.txt- the local network. In a roaming case, the local AAAA has the
../data/rfc/rfc6572.txt- visited AAA role.
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt-3. Solution Overview
../data/rfc/rfc6572.txt-
--
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt-4.19. Chargeable-User-Identity
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt- The Chargeable-User-Identity attribute, or CUI, (Type value 89) is a
../data/rfc/rfc6572.txt- unique, temporary handle used as means to, for example, correlate
../data/rfc/rfc6572.txt: authentication, accounting, and bill post-processing for a particular
../data/rfc/rfc6572.txt- chargeable subscriber. The CUI format and use follows guidelines
../data/rfc/rfc6572.txt- defined by [RFC4372].
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt- In the scope of this document, the CUI attribute MAY be present in
../data/rfc/rfc6572.txt- the Access-Request. The CUI MAY also be present in the Access-
../data/rfc/rfc6572.txt- Accept. The CUI MUST be present in the Access-Accept if it was
../data/rfc/rfc6572.txt- present in the Access-Request. If the use of the Chargeable-User-
../data/rfc/rfc6572.txt- Identity attribute is supported, then the MAG and/or the LMA commits
../data/rfc/rfc6572.txt- to include the Chargeable-User-Identity attribute in all subsequent
../data/rfc/rfc6572.txt: RADIUS Accounting packets they send for the given user.
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt-
--
../data/rfc/rfc6572.txt-6.1. Interface Operations
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt- The LMA-to-HAAA interface may be used for multiple purposes. These
../data/rfc/rfc6572.txt- include the authorization of the incoming PBU, updating the LMA
../data/rfc/rfc6572.txt- address to the HAAA, delegating the assignment of the MN-HNP or the
../data/rfc/rfc6572.txt: IPv4-HoA to the HAAA, and accounting and PMIPv6 session management.
../data/rfc/rfc6572.txt- The primary purpose of this interface is to update the HAAA with the
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt-
--
../data/rfc/rfc6572.txt- 0-1 0-1 0 0 155 PMIP6-Home-IPv4-HoA
../data/rfc/rfc6572.txt- 0-1 0-1 0 0 156 PMIP6-Visited-IPv4-HoA
../data/rfc/rfc6572.txt- 0-1 0-1 0 0 161 PMIP6-Home-IPv4-Gateway
../data/rfc/rfc6572.txt- 0-1 0-1 0 0 162 PMIP6-Visited-IPv4-Gateway
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt:7. Accounting
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt- Radius-based interfaces at the MAG and LMA with the AAA server
../data/rfc/rfc6572.txt- enables the metering of traffic associated with the MN, commonly
../data/rfc/rfc6572.txt: called "accounting". If accounting is turned on in the mobile node's
../data/rfc/rfc6572.txt- policy profile, the local routing SHOULD NOT be enabled [RFC5213].
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt:7.1. Accounting at LMA
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt: The accounting at the LMA to AAA server interface is based on
../data/rfc/rfc6572.txt- [RFC2865] and [RFC2866]. This interface MUST support the transfer of
../data/rfc/rfc6572.txt: accounting records needed for service control and charging. These
../data/rfc/rfc6572.txt- records should include (but may not be limited to) the following:
../data/rfc/rfc6572.txt- time of binding cache entry creation and deletion, number of the
../data/rfc/rfc6572.txt- octets sent and received by the MN over the bi-directional tunnel,
../data/rfc/rfc6572.txt- etc.
../data/rfc/rfc6572.txt-
--
../data/rfc/rfc6572.txt-Xia, et al. Standards Track [Page 31]
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt-RFC 6572 RADIUS PMIPv6 June 2012
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt:7.2. Accounting at MAG
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt: The accounting at the MAG to AAA server interface is based on
../data/rfc/rfc6572.txt- [RFC2865] and [RFC2866]. The interface MUST also support the
../data/rfc/rfc6572.txt: transfer of accounting records that should include the following:
../data/rfc/rfc6572.txt- time of binding cache entry creation and deletion, number of the
../data/rfc/rfc6572.txt- octets sent and received by the MN over the bi-directional tunnel,
../data/rfc/rfc6572.txt- etc.
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt- If there is data traffic between a visiting MN and a correspondent
../data/rfc/rfc6572.txt- node that is locally attached to an access link connected to the same
../data/rfc/rfc6572.txt- MAG, the mobile access gateway MAY optimize on the delivery efforts
../data/rfc/rfc6572.txt- by locally routing the packets instead of using reverse tunneling to
../data/rfc/rfc6572.txt- the mobile node's LMA. In this case, the local data traffic too MUST
../data/rfc/rfc6572.txt: be reported to AAA Accounting servers by means of RADIUS protocol.
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt-7.3. Table of Attributes
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt- The following table provides a list of attributes that may be
../data/rfc/rfc6572.txt: included in the RADIUS Accounting messages. These attributes are to
../data/rfc/rfc6572.txt: complement the set of accounting attributes already required by
../data/rfc/rfc6572.txt- [RFC2866] and [RFC2869].
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt: Accounting
../data/rfc/rfc6572.txt- Request # Attribute
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt- 0-1 145 Mobile-Node-Identifier
../data/rfc/rfc6572.txt- 0-1 146 Service-Selection
../data/rfc/rfc6572.txt- 0-1 147 PMIP6-Home-LMA-IPv6-Address
--
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt- Regarding the privacy threats associated with sending MN-specific
../data/rfc/rfc6572.txt- information between the MAG and AAA server and between the LMA and
../data/rfc/rfc6572.txt- AAA server, considerations of the RADIUS Base protocol [RFC2865],
../data/rfc/rfc6572.txt: RADIUS Accounting [RFC2866], and the RADIUS EAP application [RFC3579]
../data/rfc/rfc6572.txt- are applicable to this document. The MAG, LMA, and AAA server SHOULD
../data/rfc/rfc6572.txt- avoid including attributes containing personally identifying
../data/rfc/rfc6572.txt- information such as a MN's Interface ID, link-layer address, or NAI,
../data/rfc/rfc6572.txt- except as needed and SHOULD pay special attention if identity hiding
../data/rfc/rfc6572.txt- is desired.
--
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt- [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
../data/rfc/rfc6572.txt- Dial In User Service) Support For Extensible
../data/rfc/rfc6572.txt- Authentication Protocol (EAP)", RFC 3579, September 2003.
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt- [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS
../data/rfc/rfc6572.txt- Extensions", RFC 2869, June 2000.
../data/rfc/rfc6572.txt-
../data/rfc/rfc6572.txt- [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
--
../data/rfc/rfc4187.txt-RFC 4187 EAP-AKA Authentication January 2006
../data/rfc/rfc4187.txt-
../data/rfc/rfc4187.txt-
../data/rfc/rfc4187.txt- AAA protocol
../data/rfc/rfc4187.txt-
../data/rfc/rfc4187.txt: Authentication, Authorization and Accounting protocol
../data/rfc/rfc4187.txt-
../data/rfc/rfc4187.txt- AKA
../data/rfc/rfc4187.txt-
../data/rfc/rfc4187.txt- Authentication and Key Agreement
../data/rfc/rfc4187.txt-
--
../data/rfc/rfc739.txt- 1 1 Reserved
../data/rfc/rfc739.txt- 2-71 2-107 AHHP Regular Messages [1,3]
../data/rfc/rfc739.txt- 72-151 110-227 Reserved
../data/rfc/rfc739.txt- 152 230 PARC Universal Protocol
../data/rfc/rfc739.txt- 153 231 TIP Status Reporting
../data/rfc/rfc739.txt: 154 232 TIP Accounting
../data/rfc/rfc739.txt- 155-158 233-236 Internet Protocol [35,36]
../data/rfc/rfc739.txt- 159-191 237-277 Measurements [28]
../data/rfc/rfc739.txt- 192-195 300-303 Message Switching Protocol [4,5]
../data/rfc/rfc739.txt- 196-255 304-377 Experimental Protocols
../data/rfc/rfc739.txt-
--
../data/rfc/rfc7014.txt-RFC 7014 Flow Selection Techniques September 2013
../data/rfc/rfc7014.txt-
../data/rfc/rfc7014.txt-
../data/rfc/rfc7014.txt- of a representative subset of flows in order to estimate parameters
../data/rfc/rfc7014.txt- of the population. An adversary may have incentives to influence the
../data/rfc/rfc7014.txt: selection of flows, for example, to circumvent accounting or to avoid
../data/rfc/rfc7014.txt- the detection of packets that are part of an attack.
../data/rfc/rfc7014.txt-
../data/rfc/rfc7014.txt- Security considerations concerning the choice of a hash function for
../data/rfc/rfc7014.txt- Hash-based packet selection have been discussed in Section 6.2.3 of
../data/rfc/rfc7014.txt- [RFC5475] and are also appropriate for Hash-based Flow Selection.
--
../data/rfc/rfc7014.txt- [Dw01] Dworkin, M., "Recommendation for Block Cipher Modes of
../data/rfc/rfc7014.txt- Operation - Methods and Techniques", NIST Special
../data/rfc/rfc7014.txt- Publication 800-38A, December 2001.
../data/rfc/rfc7014.txt-
../data/rfc/rfc7014.txt- [EsVa01] Estan, C. and G,. Varghese, "New Directions in Traffic
../data/rfc/rfc7014.txt: Measurement and Accounting: Focusing on the Elephants,
../data/rfc/rfc7014.txt- Ignoring the Mice", ACM SIGCOMM Internet Measurement
../data/rfc/rfc7014.txt- Workshop (IMW) 2001, San Francisco, CA, USA,
../data/rfc/rfc7014.txt- November 2001.
../data/rfc/rfc7014.txt-
../data/rfc/rfc7014.txt- [IANA-IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities
--
../data/rfc/rfc2828.txt- - "XTACACS": The name of Cisco Corporation's implementation,
../data/rfc/rfc2828.txt- which enhances and extends the original TACACS.
../data/rfc/rfc2828.txt-
../data/rfc/rfc2828.txt- - "TACACS+": A TCP-based protocol that improves on TACACS and
../data/rfc/rfc2828.txt- XTACACS by separating the functions of authentication,
../data/rfc/rfc2828.txt: authorization, and accounting and by encrypting all traffic
../data/rfc/rfc2828.txt- between the network access server and authentication server. It
../data/rfc/rfc2828.txt- is extensible to allow any authentication mechanism to be used
../data/rfc/rfc2828.txt- with TACACS+ clients.
../data/rfc/rfc2828.txt-
../data/rfc/rfc2828.txt- $ TESS
--
../data/rfc/rfc8045.txt- IPv4 Clients to IPv4 Servers (NAT44) [RFC3022], NAT from IPv6 Clients
../data/rfc/rfc8045.txt- to IPv4 Servers (NAT64) [RFC6146], or Dual-Stack Lite Address Family
../data/rfc/rfc8045.txt- Transition Router (AFTR) [RFC6333] function. In such case, the CGN
../data/rfc/rfc8045.txt- IP transport port (e.g., TCP/UDP port) mapping behaviors can be part
../data/rfc/rfc8045.txt- of the configuration information sent from the RADIUS server to the
../data/rfc/rfc8045.txt: NAS/BNG. As part of the accounting information sent from the NAS/BNG
../data/rfc/rfc8045.txt- to a RADIUS server, the NAS/BNG may also report the IP port mapping
../data/rfc/rfc8045.txt- behavior applied by the CGN to a user session.
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt- When IP packets traverse the CGN, it performs mapping on the IP
../data/rfc/rfc8045.txt- transport (e.g., TCP/UDP) source port as required. An IP transport
--
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt- This document proposes three new attributes as RADIUS protocol
../data/rfc/rfc8045.txt- extensions; they are used for separate purposes, as follows:
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt- 1. IP-Port-Limit-Info: This attribute may be carried in a RADIUS
../data/rfc/rfc8045.txt: Access-Accept, Access-Request, Accounting-Request, or CoA-Request
../data/rfc/rfc8045.txt- packet. The purpose of this attribute is to limit the total
../data/rfc/rfc8045.txt- number of IP source transport ports allocated to a user and
../data/rfc/rfc8045.txt- associated with one or more IPv4 or IPv6 addresses.
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt- 2. IP-Port-Range: This attribute may be carried in a RADIUS
../data/rfc/rfc8045.txt: Accounting-Request packet. The purpose of this attribute is for
../data/rfc/rfc8045.txt- an address-sharing device (e.g., a CGN) to report to the RADIUS
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt-Cheng, et al. Standards Track [Page 4]
--
../data/rfc/rfc8045.txt- server the range of IP source transport ports that have been
../data/rfc/rfc8045.txt- allocated or deallocated for a user. The port range is bound to
../data/rfc/rfc8045.txt- an external IPv4 address.
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt- 3. IP-Port-Forwarding-Map: This attribute may be carried in RADIUS
../data/rfc/rfc8045.txt: Access-Accept, Access-Request, Accounting-Request, or CoA-Request
../data/rfc/rfc8045.txt- packet. The purpose of this attribute is to specify how an IP
../data/rfc/rfc8045.txt- internal source transport port, together with its internal IPv4
../data/rfc/rfc8045.txt- or IPv6 address, are mapped to an external source transport port
../data/rfc/rfc8045.txt- along with the external IPv4 address.
../data/rfc/rfc8045.txt-
--
../data/rfc/rfc8045.txt- preferred maximum number of IP ports indicated by the device
../data/rfc/rfc8045.txt- supporting port ranges co-located with the NAS, e.g., a CGN or NAT64.
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt- The IP-Port-Limit-Info Attribute MAY appear in a CoA-Request packet.
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt: The IP-Port-Limit-Info Attribute MAY appear in an Accounting-Request
../data/rfc/rfc8045.txt- packet.
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt- The IP-Port-Limit-Info Attribute MUST NOT appear in any other RADIUS
../data/rfc/rfc8045.txt- packet.
../data/rfc/rfc8045.txt-
--
../data/rfc/rfc8045.txt- end user. This TLV MUST be included in the IP-Port-Limit-Info
../data/rfc/rfc8045.txt- Attribute. Refer to Section 3.2.2. This limit applies to all
../data/rfc/rfc8045.txt- mappings that can be instantiated by an underlying address-
../data/rfc/rfc8045.txt- sharing device without soliciting any external entity. In
../data/rfc/rfc8045.txt- particular, this limit does not include the ports that are
../data/rfc/rfc8045.txt: instructed by an Authentication, Authorization, and Accounting
../data/rfc/rfc8045.txt- (AAA) server.
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt- IP-Port-Ext-IPv4-Addr TLV
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt- This TLV contains the IPv4 address that is associated with the
--
../data/rfc/rfc8045.txt- number.
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt- The information contained in the IP-Port-Range Attribute is sent to
../data/rfc/rfc8045.txt- RADIUS server.
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt: The IP-Port-Range Attribute MAY appear in an Accounting-Request
../data/rfc/rfc8045.txt- packet.
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt- The IP-Port-Range Attribute MUST NOT appear in any other RADIUS
../data/rfc/rfc8045.txt- packet.
../data/rfc/rfc8045.txt-
--
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt- The IP-Port-Forwarding-Map Attribute MAY appear in a CoA-Request
../data/rfc/rfc8045.txt- packet.
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt- The IP-Port-Forwarding-Map Attribute MAY also appear in an
../data/rfc/rfc8045.txt: Accounting-Request packet.
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt- The IP-Port-Forwarding-Map Attribute MUST NOT appear in any other
../data/rfc/rfc8045.txt- RADIUS packet.
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt-
--
../data/rfc/rfc8045.txt- the NAS, and proper configuration is accomplished on the CGN device
../data/rfc/rfc8045.txt- for that user.
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt- Also, a CGN operation status such as CGN port allocation and
../data/rfc/rfc8045.txt- deallocation for a specific user on the BNG can also be transmitted
../data/rfc/rfc8045.txt: back to the RADIUS server for accounting purposes using the RADIUS
../data/rfc/rfc8045.txt- protocol.
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt- The RADIUS protocol has already been widely deployed in broadband
../data/rfc/rfc8045.txt- networks to manage BNG, thus the functionality described in this
../data/rfc/rfc8045.txt- specification introduces little overhead to the existing network
--
../data/rfc/rfc8045.txt- | | |
../data/rfc/rfc8045.txt- | | |
../data/rfc/rfc8045.txt- | (NAT64 decides to allocate |
../data/rfc/rfc8045.txt- | a TCP/UDP port range for the user) |
../data/rfc/rfc8045.txt- | | |
../data/rfc/rfc8045.txt: | |-----Accounting-Request----->|
../data/rfc/rfc8045.txt- | | (IP-Port-Range |
../data/rfc/rfc8045.txt- | | for allocation) |
../data/rfc/rfc8045.txt- ... ... ...
../data/rfc/rfc8045.txt- | | |
../data/rfc/rfc8045.txt- | (NAT64 decides to deallocate |
../data/rfc/rfc8045.txt- | a TCP/UDP port range for the user) |
../data/rfc/rfc8045.txt- | | |
../data/rfc/rfc8045.txt: | |-----Accounting-Request----->|
../data/rfc/rfc8045.txt- | | (IP-Port-Range |
../data/rfc/rfc8045.txt- | | for deallocation) |
../data/rfc/rfc8045.txt- | | |
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt- Figure 17: RADIUS Message Flow for Reporting NAT64
--
../data/rfc/rfc8045.txt- | associate it with the |
../data/rfc/rfc8045.txt- | internal IP address |
../data/rfc/rfc8045.txt- | and external IP address) |
../data/rfc/rfc8045.txt- | | |
../data/rfc/rfc8045.txt- | | |
../data/rfc/rfc8045.txt: | |------Accounting-Request------>|
../data/rfc/rfc8045.txt- | | (IP-Port-Forwarding-Map) |
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt- Figure 18: RADIUS Message Flow for Configuring
../data/rfc/rfc8045.txt- a Port Forwarding Mapping
../data/rfc/rfc8045.txt-
--
../data/rfc/rfc8045.txt- consecutive ports, from 3500 to 3540, inclusively, and also assigns a
../data/rfc/rfc8045.txt- shared IPv4 address 192.0.2.15 for Joe. The CGN device also randomly
../data/rfc/rfc8045.txt- selects one port from the allocated range (say, 3519) and uses that
../data/rfc/rfc8045.txt- port to replace the original source port in outbound IP packets.
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt: For accounting purposes, the CGN device passes this port range
../data/rfc/rfc8045.txt- (3500-3540) and the shared IPv4 address 192.0.2.15 together to the
../data/rfc/rfc8045.txt- RADIUS server using IP-Port-Range Attribute carried by an
../data/rfc/rfc8045.txt: Accounting-Request message.
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt- When Joe works on more applications with more outbound IP mappings
../data/rfc/rfc8045.txt- and the port pool (3500-3540) is close to exhaust, the CGN device
../data/rfc/rfc8045.txt- allocates a second port pool (8500-8800) in a similar fashion and
../data/rfc/rfc8045.txt- also passes the new port range (8500-8800) and IPv4 address
../data/rfc/rfc8045.txt- 192.0.2.15 together to the RADIUS server using IP-Port-Range
../data/rfc/rfc8045.txt: Attribute carried by an Accounting-Request message. Note when the
../data/rfc/rfc8045.txt- CGN allocates more ports, it needs to assure that the total number of
../data/rfc/rfc8045.txt- ports allocated for Joe is within the limit.
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt- Joe decides to upgrade his service agreement with more TCP/UDP ports
../data/rfc/rfc8045.txt- allowed (up to 1000 ports). The ISP updates the information in Joe's
--
../data/rfc/rfc8045.txt- applications.
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt- When Joe is not using his service, most of the IP mappings are closed
../data/rfc/rfc8045.txt- with their associated TCP/UDP ports released on the CGN device, which
../data/rfc/rfc8045.txt- then sends the relevant information back to the RADIUS server using
../data/rfc/rfc8045.txt: the IP-Port-Range Attribute carried by the Accounting-Request
../data/rfc/rfc8045.txt- message.
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt- Throughout Joe's connection with his ISP, applications can
../data/rfc/rfc8045.txt- communicate with his web cam at home from the external realm, thus
../data/rfc/rfc8045.txt- directly traversing the pre-configured mapping on the CGN device.
--
../data/rfc/rfc8045.txt- |<---IP@----| | |
../data/rfc/rfc8045.txt- | | | |
../data/rfc/rfc8045.txt- | (CPE assigns a TCP/UDP port |
../data/rfc/rfc8045.txt- | range for this visiting UE) |
../data/rfc/rfc8045.txt- | | |
../data/rfc/rfc8045.txt: | |--Accounting-Request-...------------------->|
../data/rfc/rfc8045.txt- | | (IP-Port-Range |
../data/rfc/rfc8045.txt- | | for allocation) |
../data/rfc/rfc8045.txt- ... | ... ...
../data/rfc/rfc8045.txt- | | | |
../data/rfc/rfc8045.txt- | | | |
../data/rfc/rfc8045.txt- | (CPE withdraws a TCP/UDP port |
../data/rfc/rfc8045.txt- | range for a visiting UE) |
../data/rfc/rfc8045.txt- | | |
../data/rfc/rfc8045.txt: | |--Accounting-Request-...------------------->|
../data/rfc/rfc8045.txt- | | (IP-Port-Range |
../data/rfc/rfc8045.txt- | | for deallocation) |
../data/rfc/rfc8045.txt- | | |
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt- Figure 20: RADIUS Message Flow for Reporting CPE
--
../data/rfc/rfc8045.txt- length is deployment and implementation dependent. This identifier
../data/rfc/rfc8045.txt- might carry privacy-sensitive information. It is therefore
../data/rfc/rfc8045.txt- RECOMMENDED to utilize identifiers that do not have such privacy
../data/rfc/rfc8045.txt- concerns.
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt: If there is any error in a RADIUS Accounting-Request packet sent
../data/rfc/rfc8045.txt- from a RADIUS client to the server, the RADIUS server MUST NOT send
../data/rfc/rfc8045.txt- a response to the client (refer to [RFC2866]). Examples of the
../data/rfc/rfc8045.txt- errors include the erroneous port range in the
../data/rfc/rfc8045.txt- IP-Port-Range Attribute, inconsistent port mapping in the
../data/rfc/rfc8045.txt- IP-Port-Forwarding-Map Attribute, etc.
--
../data/rfc/rfc8045.txt- [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
../data/rfc/rfc8045.txt- and E. Lear, "Address Allocation for Private Internets",
../data/rfc/rfc8045.txt- BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
../data/rfc/rfc8045.txt- <http://www.rfc-editor.org/info/rfc1918>.
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866,
../data/rfc/rfc8045.txt- DOI 10.17487/RFC2866, June 2000,
../data/rfc/rfc8045.txt- <http://www.rfc-editor.org/info/rfc2866>.
../data/rfc/rfc8045.txt-
../data/rfc/rfc8045.txt- [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
../data/rfc/rfc8045.txt- Address Translator (Traditional NAT)", RFC 3022,
--
../data/rfc/rfc5619.txt- As the softwire deployment model, the following three cases as shown
../data/rfc/rfc5619.txt- in Figure 1 should be considered. Cases 2 and 3 are typical for a
../data/rfc/rfc5619.txt- nomadic node, but are also applicable to a stationary node. In order
../data/rfc/rfc5619.txt- to securely connect a legitimate SI and SC to each other, the
../data/rfc/rfc5619.txt- authentication process between SI and SC is normally performed using
../data/rfc/rfc5619.txt: Authentication, Authorization, and Accounting (AAA) servers.
../data/rfc/rfc5619.txt-
../data/rfc/rfc5619.txt-
../data/rfc/rfc5619.txt-
../data/rfc/rfc5619.txt-
../data/rfc/rfc5619.txt-
--
../data/rfc/rfc5619.txt- and the visited AAA server may consist of several AAA proxies. In
../data/rfc/rfc5619.txt- this case, the AAA proxy threat model SHOULD be considered [RFC2607].
../data/rfc/rfc5619.txt- A malicious AAA proxy may launch passive or active security attacks.
../data/rfc/rfc5619.txt- The trustworthiness of proxies in AAA proxy chains will weaken when
../data/rfc/rfc5619.txt- the hop counts of the proxy chain is longer. For example, the
../data/rfc/rfc5619.txt: accounting information exchanged among AAA proxies is attractive for
../data/rfc/rfc5619.txt- an adversary. The communication between a home AAA server and a
../data/rfc/rfc5619.txt- visited AAA server MUST be protected.
../data/rfc/rfc5619.txt-
../data/rfc/rfc5619.txt-3.3. Softwire Security Threat Scenarios
../data/rfc/rfc5619.txt-
--
../data/rfc/rfc3552.txt-
../data/rfc/rfc3552.txt-
../data/rfc/rfc3552.txt- trusted in the given context. For instance, users who possess
../data/rfc/rfc3552.txt- certificates issued by the Acme MIS CA may have different web access
../data/rfc/rfc3552.txt- privileges than users who possess certificates issued by the Acme
../data/rfc/rfc3552.txt: Accounting CA, even though both of these CAs are "trusted" by the
../data/rfc/rfc3552.txt- Acme web server.
../data/rfc/rfc3552.txt-
../data/rfc/rfc3552.txt- Mechanisms for enforcing these more complicated properties have not
../data/rfc/rfc3552.txt- yet been completely explored. One approach is simply to attach
../data/rfc/rfc3552.txt- policies to ACLs describing what sorts of certificates are trusted.
--
../data/rfc/rfc160.txt- Response to RFC 116 5849 131
../data/rfc/rfc160.txt- Typographical Error in RFC 107 6708 132
../data/rfc/rfc160.txt- File Transfer and Error Recovery 6710 133
../data/rfc/rfc160.txt- Network Meeting 6711 134
../data/rfc/rfc160.txt- Response to NWG/RFC 110 6712 135
../data/rfc/rfc160.txt: Host Accounting and Administrative Procedures 6713 136
../data/rfc/rfc160.txt- TELNET Protocol - A Proposed Document 6714 137
../data/rfc/rfc160.txt- Status Report on Proposed Data Reconfiguration 6715 138
../data/rfc/rfc160.txt- Discussion of Proposed TELNET 6717 139
../data/rfc/rfc160.txt- Agenda for May NWG Meeting 6725 140
../data/rfc/rfc160.txt- Comments on RFC 114 (A File Transfer Protocol) 6726 141
--
../data/rfc/rfc1322.txt- time. The setup protocol defines packet formats and the processing
../data/rfc/rfc1322.txt- of route installation request packets (i.e, setup packets). When a
../data/rfc/rfc1322.txt- source generates a setup packet, the first border router along the
../data/rfc/rfc1322.txt- specified source route checks the setup request, and if accepted,
../data/rfc/rfc1322.txt- installs routing information; this information includes a path ID,
../data/rfc/rfc1322.txt: the previous and next hops, and whatever other accounting-related
../data/rfc/rfc1322.txt- information the particular domain requires. The setup packet is
../data/rfc/rfc1322.txt- passed on to the next BR in the domain-level source route, and the
../data/rfc/rfc1322.txt- same procedure is carried out [Footnote: The setup packet may be
../data/rfc/rfc1322.txt- forwarded optimistically, i.e., before checks are completed, to
../data/rfc/rfc1322.txt- reduce latency.]. When the setup packet reaches the destination, an
--
../data/rfc/rfc333.txt- network. The library process has a RECEIVE from ANY always pending
../data/rfc/rfc333.txt- at a well-known port. Eventually, some process sends a message to
../data/rfc/rfc333.txt- the library process' well-known-port. This message includes the data
../data/rfc/rfc333.txt- to be processed, a port to use for sending the answer, and the money.
../data/rfc/rfc333.txt- The library process takes some of the money and sends it to the
../data/rfc/rfc333.txt: well-known port of the accounting process which itself has a RECEIVE
../data/rfc/rfc333.txt- from ANY pending. The library process then processes the data and
../data/rfc/rfc333.txt- sends the answer back to the process which requested the service
../data/rfc/rfc333.txt- using a SEND to SPECIFIC message which rendezvous at the destination
../data/rfc/rfc333.txt- where there is already a RECEIVE from SPECIFIC pending. Of course,
../data/rfc/rfc333.txt- in this message besides the answer, any change the requesting process
--
../data/rfc/rfc8994.txt- the data plane are configured correctly, will the data plane and the
../data/rfc/rfc8994.txt- OAM and/or control plane work as expected.
../data/rfc/rfc8994.txt-
../data/rfc/rfc8994.txt- Data plane connectivity can be affected by errors and faults.
../data/rfc/rfc8994.txt- Examples include misconfigurations that make AAA (Authentication,
../data/rfc/rfc8994.txt: Authorization, and Accounting) servers unreachable or that can lock
../data/rfc/rfc8994.txt- an administrator out of a device; routing or addressing issues can
../data/rfc/rfc8994.txt- make a device unreachable; and shutting down interfaces over which a
../data/rfc/rfc8994.txt- current management session is running can lock an administrator
../data/rfc/rfc8994.txt- irreversibly out of the device. Traditionally only out-of-band
../data/rfc/rfc8994.txt- access via a serial console or Ethernet management port can help
--
../data/rfc/rfc2378.txt- Prints the message of the day and the current status of the
../data/rfc/rfc2378.txt- nameserver.
../data/rfc/rfc2378.txt-
../data/rfc/rfc2378.txt- C: status
../data/rfc/rfc2378.txt- S: 100:Qi server $Revision: 1.6 $
../data/rfc/rfc2378.txt: S: 100:Ph passwords may be obtained at CCSO Accounting,
../data/rfc/rfc2378.txt- S: 100:1420 Digital Computer Lab, between 8:30 and 5 Monday-Friday.
../data/rfc/rfc2378.txt- S: 100:Be sure to bring your U of I ID card.
../data/rfc/rfc2378.txt- S: 200:Database ready
../data/rfc/rfc2378.txt-
../data/rfc/rfc2378.txt-3.2. siteinfo
--
../data/rfc/rfc3675.txt- Internet governance, and raise concerns about forced speech and
../data/rfc/rfc3675.txt- self-labeling.
../data/rfc/rfc3675.txt-
../data/rfc/rfc3675.txt- In fact, the ultimate arbiter of generic top-level domain names -- at
../data/rfc/rfc3675.txt- least currently -- is not ICANN, but the U.S. government. The U.S.
../data/rfc/rfc3675.txt: Congress' General Accounting Office in July 2000 reported that the
../data/rfc/rfc3675.txt- Commerce Department continues to be responsible for domain names
../data/rfc/rfc3675.txt- allowed by the authoritative root [GAO]. The GAO's auditors
../data/rfc/rfc3675.txt- concluded it was unclear whether the Commerce Department has the
../data/rfc/rfc3675.txt- "requisite authority" under current law to transfer that
../data/rfc/rfc3675.txt- responsibility to ICANN.
--
../data/rfc/rfc33.txt- contributed to the following design philosophy.
../data/rfc/rfc33.txt-
../data/rfc/rfc33.txt- First, because the computers in the network have independent purposes
../data/rfc/rfc33.txt- it is necessary to preserve decentralized administrative control of
../data/rfc/rfc33.txt- the various computers. Since all of the time-sharing supervisors
../data/rfc/rfc33.txt: possess elaborate and definite accounting and resource allocation
../data/rfc/rfc33.txt-
../data/rfc/rfc33.txt-
../data/rfc/rfc33.txt-
../data/rfc/rfc33.txt-Crocker, et. al. [Page 4]
../data/rfc/rfc33.txt-
--
../data/rfc/rfc5226.txt- To ensure adequate community review, such documents are
../data/rfc/rfc5226.txt- shepherded through the IESG as AD-sponsored (or WG)
../data/rfc/rfc5226.txt- documents with an IETF Last Call.
../data/rfc/rfc5226.txt-
../data/rfc/rfc5226.txt- Examples: IPSECKEY Algorithm Types [RFC4025],
../data/rfc/rfc5226.txt: Accounting-Auth-Method AVP values in DIAMETER [RFC4005], TLS
../data/rfc/rfc5226.txt- Handshake Hello Extensions [RFC4366].
../data/rfc/rfc5226.txt-
../data/rfc/rfc5226.txt- Standards Action - Values are assigned only for Standards Track
../data/rfc/rfc5226.txt- RFCs approved by the IESG.
../data/rfc/rfc5226.txt-
--
../data/rfc/rfc6678.txt- [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
../data/rfc/rfc6678.txt- Authentication Protocol (EAP) Method Requirements for
../data/rfc/rfc6678.txt- Wireless LANs", RFC 4017, March 2005.
../data/rfc/rfc6678.txt-
../data/rfc/rfc6678.txt- [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
../data/rfc/rfc6678.txt: Authorization, and Accounting (AAA) Key Management",
../data/rfc/rfc6678.txt- BCP 132, RFC 4962, July 2007.
../data/rfc/rfc6678.txt-
../data/rfc/rfc6678.txt- [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and
../data/rfc/rfc6678.txt- W. Polk, "Server-Based Certificate Validation Protocol
../data/rfc/rfc6678.txt- (SCVP)", RFC 5055, December 2007.
--
../data/rfc/rfc6463.txt- transparent at the PMIPv6 protocol level and do not depend on the
../data/rfc/rfc6463.txt- functionality defined in this specification.
../data/rfc/rfc6463.txt-
../data/rfc/rfc6463.txt- The runtime LMA assignment functionality does not depend on the
../data/rfc/rfc6463.txt- Domain Name System (DNS) or the Authentication, Authorization, and
../data/rfc/rfc6463.txt: Accounting (AAA) infrastructure for the assignment of the LMA to
../data/rfc/rfc6463.txt- which the mobile node (MN) is anchored. All MAGs and LMAs (either
../data/rfc/rfc6463.txt- rfLMAs or r2LMAs; see Section 2.2) have to belong to the same PMIPv6
../data/rfc/rfc6463.txt- domain.
../data/rfc/rfc6463.txt-
../data/rfc/rfc6463.txt- There are a number of reasons why the runtime LMA assignment is a
--
../data/rfc/rfc4396.txt- Every sample description MUST have its own TYPE 5 header.
../data/rfc/rfc4396.txt-
../data/rfc/rfc4396.txt- The U, R, and TYPE fields are used as per Section 4.1.1.
../data/rfc/rfc4396.txt-
../data/rfc/rfc4396.txt- The LEN field indicates the length of the sample description, plus
../data/rfc/rfc4396.txt: three units accounting for the SIDX and LEN field itself. Thus, this
../data/rfc/rfc4396.txt- field MUST be greater than three (0x0003). Otherwise, the unit MUST
../data/rfc/rfc4396.txt- be discarded.
../data/rfc/rfc4396.txt-
../data/rfc/rfc4396.txt- If the sample is streamed from a 3GP file, the length of the sample
../data/rfc/rfc4396.txt- description contents (i.e., what comes after SIDX in the unit itself)
--
../data/rfc/rfc5867.txt- single trade may have multiple independent teams working
../data/rfc/rfc5867.txt- simultaneously. Furthermore, the HVAC, lighting, and fire systems
../data/rfc/rfc5867.txt- must be fully operational before the building can obtain its
../data/rfc/rfc5867.txt- occupancy permit. Hence, the BMS must be in place and configured
../data/rfc/rfc5867.txt- well before any of the IT servers (DHCP; Authentication,
../data/rfc/rfc5867.txt: Authorization, and Accounting (AAA); DNS; etc.) are operational.
../data/rfc/rfc5867.txt-
../data/rfc/rfc5867.txt-
../data/rfc/rfc5867.txt-
../data/rfc/rfc5867.txt-Martocci, et al. Informational [Page 8]
../data/rfc/rfc5867.txt-
--
../data/rfc/rfc4258.txt-
../data/rfc/rfc4258.txt- Management plane: Performs management functions for the transport
../data/rfc/rfc4258.txt- plane, the control plane, and the system as a whole. It also
../data/rfc/rfc4258.txt- provides coordination between all the planes. The following
../data/rfc/rfc4258.txt- management functional areas are performed in the management plane:
../data/rfc/rfc4258.txt: performance, fault, configuration, accounting, and security
../data/rfc/rfc4258.txt- management.
../data/rfc/rfc4258.txt-
../data/rfc/rfc4258.txt-
../data/rfc/rfc4258.txt-
../data/rfc/rfc4258.txt-
--
../data/rfc/rfc1126.txt- recently installed fiber cables provide abundant communication
../data/rfc/rfc1126.txt- bandwidths, while old narrow-band channels will still be with us for
../data/rfc/rfc1126.txt- a long time period. Electronic mail traffic tolerates delivery
../data/rfc/rfc1126.txt- delays and low throughput. New image transmissions are coming up;
../data/rfc/rfc1126.txt- these require high bandwidths but are not effected by a few bit
../data/rfc/rfc1126.txt: errors. Furthermore, some networks may soon install accounting
../data/rfc/rfc1126.txt- functions to charge users, while others may still provide free
../data/rfc/rfc1126.txt- services.
../data/rfc/rfc1126.txt-
../data/rfc/rfc1126.txt- Considering the long life span of a new routing architecture, it is
../data/rfc/rfc1126.txt- mandatory that it be built with mechanisms to provide TOS routing.
--
../data/rfc/rfc6807.txt- Population Count Extensions to Protocol Independent Multicast (PIM)
../data/rfc/rfc6807.txt-
../data/rfc/rfc6807.txt-Abstract
../data/rfc/rfc6807.txt-
../data/rfc/rfc6807.txt- This specification defines a method for providing multicast
../data/rfc/rfc6807.txt: distribution-tree accounting data. Simple extensions to the Protocol
../data/rfc/rfc6807.txt- Independent Multicast (PIM) protocol allow a rough approximation of
../data/rfc/rfc6807.txt- tree-based data in a scalable fashion.
../data/rfc/rfc6807.txt-
../data/rfc/rfc6807.txt-Status of This Memo
../data/rfc/rfc6807.txt-
--
../data/rfc/rfc6807.txt-RFC 6807 Population Count Extensions to PIM December 2012
../data/rfc/rfc6807.txt-
../data/rfc/rfc6807.txt-
../data/rfc/rfc6807.txt-1. Introduction
../data/rfc/rfc6807.txt-
../data/rfc/rfc6807.txt: This document specifies a mechanism to convey accounting information
../data/rfc/rfc6807.txt- using the Protocol Independent Multicast (PIM) protocol [RFC4601]
../data/rfc/rfc6807.txt- [RFC5015]. Putting the mechanism in PIM allows efficient
../data/rfc/rfc6807.txt: distribution and maintenance of such accounting information.
../data/rfc/rfc6807.txt- Previous mechanisms require data to be correlated from multiple
../data/rfc/rfc6807.txt- router sources.
../data/rfc/rfc6807.txt-
../data/rfc/rfc6807.txt- This mechanism allows a single router to be queried to obtain
../data/rfc/rfc6807.txt: accounting and statistic information for a multicast distribution
../data/rfc/rfc6807.txt- tree as a whole or any distribution sub-tree downstream from a
../data/rfc/rfc6807.txt- queried router. The amount of information is fixed and does not
../data/rfc/rfc6807.txt- increase as multicast membership, tree diameter, or branching
../data/rfc/rfc6807.txt- increases.
../data/rfc/rfc6807.txt-
../data/rfc/rfc6807.txt: The sort of accounting data this specification provides, on a per-
../data/rfc/rfc6807.txt- multicast-route basis, are:
../data/rfc/rfc6807.txt-
../data/rfc/rfc6807.txt- 1. The number of branches in a distribution tree.
../data/rfc/rfc6807.txt-
../data/rfc/rfc6807.txt- 2. The membership type of the distribution tree, that is, Source-
--
../data/rfc/rfc6807.txt-
../data/rfc/rfc6807.txt- P flag: This flag is set by a router if all downstream routers
../data/rfc/rfc6807.txt- support this specification. That is, they are all PIM Pop-
../data/rfc/rfc6807.txt- Count capable. If a downstream router does not support this
../data/rfc/rfc6807.txt- specification, it MUST be cleared. This allows one to tell if
../data/rfc/rfc6807.txt: the entire sub-tree is completely accounting capable.
../data/rfc/rfc6807.txt-
../data/rfc/rfc6807.txt- Options Bitmap: This is a bitmap that shows which options are
../data/rfc/rfc6807.txt- present. The format of the bitmap is as follows:
../data/rfc/rfc6807.txt-
../data/rfc/rfc6807.txt- 0 1
--
../data/rfc/rfc6807.txt-
../data/rfc/rfc6807.txt- It is also RECOMMENDED that join suppression be disabled on a LAN
../data/rfc/rfc6807.txt- when Pop-Count is used.
../data/rfc/rfc6807.txt-
../data/rfc/rfc6807.txt- It is RECOMMENDED that, when triggered Join/Prune messages are sent
../data/rfc/rfc6807.txt: by a downstream router, the accounting information not be included in
../data/rfc/rfc6807.txt- the message. This way, when convergence is important, avoiding the
../data/rfc/rfc6807.txt: processing time to build an accounting record in a downstream router
../data/rfc/rfc6807.txt- and processing time to parse the message in the upstream router will
../data/rfc/rfc6807.txt- help reduce convergence time. If an upstream router receives a Join/
../data/rfc/rfc6807.txt: Prune message with no accounting data, it SHOULD NOT interpret the
../data/rfc/rfc6807.txt: message as a trigger to clear or reset the accounting data it has
../data/rfc/rfc6807.txt- cached.
../data/rfc/rfc6807.txt-
../data/rfc/rfc6807.txt-5. Implementation Approaches
../data/rfc/rfc6807.txt-
../data/rfc/rfc6807.txt- This section offers some non-normative suggestions for how Pop-Count
../data/rfc/rfc6807.txt- may be implemented.
../data/rfc/rfc6807.txt-
../data/rfc/rfc6807.txt: An implementation can decide how the accounting attributes are
../data/rfc/rfc6807.txt- maintained. The values can be stored as part of the multicast route
../data/rfc/rfc6807.txt- data structure by combining the local information it has with the
../data/rfc/rfc6807.txt- joined information on a per-oif basis. So, when it is time to send a
../data/rfc/rfc6807.txt- Join/Prune message, the values stored in the multicast route can be
../data/rfc/rfc6807.txt- copied to the message.
../data/rfc/rfc6807.txt-
../data/rfc/rfc6807.txt: Or, an implementation could store the accounting values per oif and,
../data/rfc/rfc6807.txt- when a Join/Prune message is sent, it can combine the oifs with its
../data/rfc/rfc6807.txt- local information. Then, the combined information can be copied to
../data/rfc/rfc6807.txt- the message.
../data/rfc/rfc6807.txt-
../data/rfc/rfc6807.txt-
--
../data/rfc/rfc6807.txt-Farinacci, et al. Experimental [Page 12]
../data/rfc/rfc6807.txt-
../data/rfc/rfc6807.txt-RFC 6807 Population Count Extensions to PIM December 2012
../data/rfc/rfc6807.txt-
../data/rfc/rfc6807.txt-
../data/rfc/rfc6807.txt: When a downstream joiner stops joining, accounting values cached must
../data/rfc/rfc6807.txt- be evaluated. There are two approaches that can be taken. One is to
../data/rfc/rfc6807.txt- keep values learned from each joiner, so when the joiner goes away,
../data/rfc/rfc6807.txt- the count/max/min values are known and the combined value can be
../data/rfc/rfc6807.txt- adjusted. The other approach is to set the value to 0 for the oif,
../data/rfc/rfc6807.txt- and then start accumulating new values as subsequent Joins are
--
../data/rfc/rfc6807.txt- the route).
../data/rfc/rfc6807.txt-
../data/rfc/rfc6807.txt-6. Caveats
../data/rfc/rfc6807.txt-
../data/rfc/rfc6807.txt- This specification requires each router on a multicast distribution
../data/rfc/rfc6807.txt: tree to support this specification or else the accounting attributes
../data/rfc/rfc6807.txt- for the tree will not be known.
../data/rfc/rfc6807.txt-
../data/rfc/rfc6807.txt- However, if there is a contiguous set of routers downstream in the
../data/rfc/rfc6807.txt: distribution tree, they can maintain accounting information for the
../data/rfc/rfc6807.txt- sub-tree.
../data/rfc/rfc6807.txt-
../data/rfc/rfc6807.txt- If there is a set of contiguous routers supporting this specification
../data/rfc/rfc6807.txt: upstream on the multicast distribution tree, accounting information
../data/rfc/rfc6807.txt- will be available, but it will not represent an accurate assessment
../data/rfc/rfc6807.txt- of the entire tree. Also, it will not be clear how much of the
../data/rfc/rfc6807.txt: distribution tree the accounting information covers.
../data/rfc/rfc6807.txt-
../data/rfc/rfc6807.txt-7. IANA Considerations
../data/rfc/rfc6807.txt-
../data/rfc/rfc6807.txt- A new PIM-Hello Option type, 29, has been assigned by IANA. Although
../data/rfc/rfc6807.txt- the length is specified as 0 in this specification, non-zero length
--
../data/rfc/rfc8192.txt-RFC 8192 I2NSF Problem Statement & Use Cases July 2017
../data/rfc/rfc8192.txt-
../data/rfc/rfc8192.txt-
../data/rfc/rfc8192.txt-2. Terminology
../data/rfc/rfc8192.txt-
../data/rfc/rfc8192.txt: AAA: Authentication, Authorization, and Accounting [RFC2904]
../data/rfc/rfc8192.txt-
../data/rfc/rfc8192.txt- ACL: Access Control List
../data/rfc/rfc8192.txt-
../data/rfc/rfc8192.txt- Bespoke security management: Security management that is made to fit
../data/rfc/rfc8192.txt- a particular customer.
--
../data/rfc/rfc105.txt-II - Remote Job Output Retrieval (RJOR)
../data/rfc/rfc105.txt-
../data/rfc/rfc105.txt- Class A SYSOUT output from jobs submitted through RJE for batch
../data/rfc/rfc105.txt-processing at UCSB may be obtained by contacting socket x'300', site 3,
../data/rfc/rfc105.txt-provided that when the job was submitted, the character 'T' appeared as
../data/rfc/rfc105.txt:the eighth positional accounting parameter on the job card. Output is
../data/rfc/rfc105.txt-retrieved upon request and relayed to the Network user by a process
../data/rfc/rfc105.txt-hereafter called RJOR which is addressed as socket x'300'. RJOR can be
../data/rfc/rfc105.txt-invoked through the Logger. This section is intended to provide
../data/rfc/rfc105.txt-programmers with the information necessary to communicate with RJOR.
../data/rfc/rfc105.txt-
--
../data/rfc/rfc6911.txt-
../data/rfc/rfc6911.txt-Abstract
../data/rfc/rfc6911.txt-
../data/rfc/rfc6911.txt- This document specifies additional IPv6 RADIUS Attributes useful in
../data/rfc/rfc6911.txt- residential broadband network deployments. The Attributes, which are
../data/rfc/rfc6911.txt: used for authorization and accounting, enable assignment of a host
../data/rfc/rfc6911.txt- IPv6 address and an IPv6 DNS server address via DHCPv6, assignment of
../data/rfc/rfc6911.txt- an IPv6 route announced via router advertisement, assignment of a
../data/rfc/rfc6911.txt- named IPv6 delegated prefix pool, and assignment of a named IPv6 pool
../data/rfc/rfc6911.txt- for host DHCPv6 addressing.
../data/rfc/rfc6911.txt-
--
../data/rfc/rfc6911.txt- a wide variety of network access scenarios in which RADIUS is
../data/rfc/rfc6911.txt- involved. One such typical network scenario is illustrated in Figure
../data/rfc/rfc6911.txt- 1. It is composed of an IP Routing Residential Gateway (RG) or host;
../data/rfc/rfc6911.txt- a Layer 2 Access Node (AN), e.g., a Digital Subscriber Line Access
../data/rfc/rfc6911.txt- Multiplexer (DSLAM); an IP Network Access Server (NAS) (incorporating
../data/rfc/rfc6911.txt: an Authentication, Authorization, and Accounting (AAA) client); and a
../data/rfc/rfc6911.txt- AAA server.
../data/rfc/rfc6911.txt-
../data/rfc/rfc6911.txt-
../data/rfc/rfc6911.txt-
../data/rfc/rfc6911.txt-
--
../data/rfc/rfc6911.txt- Figure 1
../data/rfc/rfc6911.txt-
../data/rfc/rfc6911.txt- In the depicted scenario, the NAS may utilize an IP address
../data/rfc/rfc6911.txt- configuration protocol (e.g., DHCPv6) to handle address assignment to
../data/rfc/rfc6911.txt- RGs/hosts. The RADIUS server authenticates each RG/host and returns
../data/rfc/rfc6911.txt: the Attributes used for authorization and accounting. These
../data/rfc/rfc6911.txt- Attributes can include a host's IPv6 address, a DNS server address,
../data/rfc/rfc6911.txt- and a set of IPv6 routes to be advertised via any suitable protocol,
../data/rfc/rfc6911.txt- e.g., ICMPv6 (Neighbor Discovery). The name of a prefix pool to be
../data/rfc/rfc6911.txt- used for DHCPv6 Prefix Delegation or the name of an address pool to
../data/rfc/rfc6911.txt- be used for DHCPv6 address assignment can also be Attributes provided
--
../data/rfc/rfc6911.txt- While [RFC3162] permits the specification of an IPv6 address via the
../data/rfc/rfc6911.txt- combination of the Framed-Interface-Id and Framed-IPv6-Prefix
../data/rfc/rfc6911.txt- Attributes, this separation is more natural for use with PPP's IPv6
../data/rfc/rfc6911.txt- Control Protocol than it is for use with DHCPv6, and the use of a
../data/rfc/rfc6911.txt- single IPv6 address Attribute makes for easier processing of
../data/rfc/rfc6911.txt: accounting records.
../data/rfc/rfc6911.txt-
../data/rfc/rfc6911.txt-
../data/rfc/rfc6911.txt-
../data/rfc/rfc6911.txt-
../data/rfc/rfc6911.txt-
--
../data/rfc/rfc6911.txt- that the NAS will require both stateful and stateless configuration
../data/rfc/rfc6911.txt- information. Therefore, it is possible for the Framed-IPv6-Address,
../data/rfc/rfc6911.txt- Framed-IPv6-Prefix, and Framed-Interface-Id Attributes [RFC3162] to
../data/rfc/rfc6911.txt- be included within the same packet. To avoid ambiguity in this case,
../data/rfc/rfc6911.txt- the Framed-IPv6-Address Attribute is intended for authorization and
../data/rfc/rfc6911.txt: accounting of DHCPv6-assigned addresses, and the Framed-IPv6-Prefix
../data/rfc/rfc6911.txt- and Framed-Interface-Id Attributes are used for authorization and
../data/rfc/rfc6911.txt: accounting of addresses assigned via SLAAC.
../data/rfc/rfc6911.txt-
../data/rfc/rfc6911.txt-2.2. DNS Servers
../data/rfc/rfc6911.txt-
../data/rfc/rfc6911.txt- DHCPv6 provides an option for configuring a host with the IPv6
../data/rfc/rfc6911.txt- address of a DNS server. The IPv6 address of a DNS server can also
--
../data/rfc/rfc6911.txt- Because DHCPv6 Prefix Delegation can be used with SLAAC on the same
../data/rfc/rfc6911.txt- network, it is possible for the Delegated-IPv6-Prefix-Pool and
../data/rfc/rfc6911.txt- Framed-IPv6-Pool Attributes to be included within the same packet.
../data/rfc/rfc6911.txt- To avoid ambiguity in this scenario, use of the Delegated-IPv6-
../data/rfc/rfc6911.txt- Prefix-Pool Attribute should be restricted to authorization and
../data/rfc/rfc6911.txt: accounting of prefix pools used in DHCPv6 Prefix Delegation, and the
../data/rfc/rfc6911.txt- Framed-IPv6-Pool Attribute should be used for authorization and
../data/rfc/rfc6911.txt: accounting of prefix pools used in SLAAC.
../data/rfc/rfc6911.txt-
../data/rfc/rfc6911.txt-2.5. Stateful IPv6 Address Pool
../data/rfc/rfc6911.txt-
../data/rfc/rfc6911.txt- DHCPv6 [RFC3315] provides a mechanism to assign one or more non-
../data/rfc/rfc6911.txt- temporary IPv6 addresses to hosts. Section 3.1 introduces the
--
../data/rfc/rfc6911.txt- the clients. An alternative way to achieve a similar result is for
../data/rfc/rfc6911.txt- the NAS to select the IPv6 address to be assigned from an address
../data/rfc/rfc6911.txt- pool configured for this purpose on the NAS. This document specifies
../data/rfc/rfc6911.txt- the Stateful-IPv6-Address-Pool Attribute (Section 3.5) to allow the
../data/rfc/rfc6911.txt- RADIUS server to convey a pool name to be used for such stateful
../data/rfc/rfc6911.txt: DHCPv6-based addressing and for any subsequent accounting.
../data/rfc/rfc6911.txt-
../data/rfc/rfc6911.txt-3. Attributes
../data/rfc/rfc6911.txt-
../data/rfc/rfc6911.txt- The fields shown in the diagrams below are transmitted from left to
../data/rfc/rfc6911.txt- right.
--
../data/rfc/rfc6911.txt-Dec, et al. Standards Track [Page 11]
../data/rfc/rfc6911.txt-
../data/rfc/rfc6911.txt-RFC 6911 RADIUS IPv6 Access April 2013
../data/rfc/rfc6911.txt-
../data/rfc/rfc6911.txt-
../data/rfc/rfc6911.txt: Request Accept Reject Challenge Accounting # Attribute
../data/rfc/rfc6911.txt- Request
../data/rfc/rfc6911.txt- 0+ 0+ 0 0 0+ 168 Framed-IPv6-Address
../data/rfc/rfc6911.txt- 0+ 0+ 0 0 0+ 169 DNS-Server-IPv6-Address
../data/rfc/rfc6911.txt- 0+ 0+ 0 0 0+ 170 Route-IPv6-Information
../data/rfc/rfc6911.txt- 0+ 0+ 0 0 0+ 171 Delegated-IPv6-Prefix-Pool
--
../data/rfc/rfc3289.txt- should have a corresponding counter. In early versions, it was
../data/rfc/rfc3289.txt- impossible to configure an action without implementing a counter,
../data/rfc/rfc3289.txt- although the current design makes them in effect the network
../data/rfc/rfc3289.txt- manager's option, as a result of making actions consistent in
../data/rfc/rfc3289.txt- structure and extensibility. The assurance of proper debugging and
../data/rfc/rfc3289.txt: accounting is therefore left with the policy designer.
../data/rfc/rfc3289.txt-
../data/rfc/rfc3289.txt- When the MIB is used for configuration, diffServCountActNextFree
../data/rfc/rfc3289.txt- always contains a legal value for diffServCountActId that is not
../data/rfc/rfc3289.txt- currently used in the system's configuration.
../data/rfc/rfc3289.txt-
--
../data/rfc/rfc4137.txt-Abstract
../data/rfc/rfc4137.txt-
../data/rfc/rfc4137.txt- This document describes a set of state machines for Extensible
../data/rfc/rfc4137.txt- Authentication Protocol (EAP) peer, EAP stand-alone authenticator
../data/rfc/rfc4137.txt- (non-pass-through), EAP backend authenticator (for use on
../data/rfc/rfc4137.txt: Authentication, Authorization, and Accounting (AAA) servers), and EAP
../data/rfc/rfc4137.txt- full authenticator (for both local and pass-through). This set of
../data/rfc/rfc4137.txt- state machines shows how EAP can be implemented to support deployment
../data/rfc/rfc4137.txt- in either a peer/authenticator or peer/authenticator/AAA Server
../data/rfc/rfc4137.txt- environment. The peer and stand-alone authenticator machines are
../data/rfc/rfc4137.txt- illustrative of how the EAP protocol defined in RFC 3748 may be
--
../data/rfc/rfc1068.txt-
../data/rfc/rfc1068.txt- o Deferred Delivery
../data/rfc/rfc1068.txt-
../data/rfc/rfc1068.txt- The user may wish to defer a large transfer until an off-peak
../data/rfc/rfc1068.txt- period. This may become important when parts of the Internet
../data/rfc/rfc1068.txt: adopt accounting and traffic-based cost-recovery mechanisms.
../data/rfc/rfc1068.txt-
../data/rfc/rfc1068.txt-
../data/rfc/rfc1068.txt- There is a serious human-engineering problem with background file
../data/rfc/rfc1068.txt- transfer: if the user makes a mistake in entering parameters, this
../data/rfc/rfc1068.txt- mistake may not become apparent until much later. This can be the
--
../data/rfc/rfc874.txt- 1-3. ("Loose constructionists" of the ISORM would hold that X.25
../data/rfc/rfc874.txt- is a mechanization of L1-L3 rather than the mechanization, and at
../data/rfc/rfc874.txt- least one British source holds that "we in the U.K. don't believe
../data/rfc/rfc874.txt- that ISO have adopted X.25.") In the U.S. Government arena,
../data/rfc/rfc874.txt- where the author spends much of his time, the Government
../data/rfc/rfc874.txt: Accounting Office (GAO) has suggested that the Department of
../data/rfc/rfc874.txt- Defense (DoD) ought to consider adopting "X.25 networks,"
../data/rfc/rfc874.txt- apparently in preference to networks based on protocols developed
../data/rfc/rfc874.txt- by the DoD-sponsored intercomputer networking research community.
../data/rfc/rfc874.txt- That intercomputer networking research community in turn has,
../data/rfc/rfc874.txt- with a few recent exceptions, adhered to its commitment to the
--
../data/rfc/rfc4067.txt-
../data/rfc/rfc4067.txt- [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
../data/rfc/rfc4067.txt- 2631, June 1999.
../data/rfc/rfc4067.txt-
../data/rfc/rfc4067.txt- [PerkCal04] Perkins, C. and P. Calhoun, "Authentication,
../data/rfc/rfc4067.txt: Authorization, and Accounting (AAA) Registration Keys for
../data/rfc/rfc4067.txt- Mobile IPv4", RFC 3957, March 2005.
../data/rfc/rfc4067.txt-
../data/rfc/rfc4067.txt- [MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
../data/rfc/rfc4067.txt- in IPv6", RFC 3775, June 2004.
../data/rfc/rfc4067.txt-
--
../data/rfc/rfc4067.txt-
../data/rfc/rfc4067.txt-Appendix B. Multicast Listener Context Transfer
../data/rfc/rfc4067.txt-
../data/rfc/rfc4067.txt- In the past, credible proposals have been made in the Seamoby Working
../data/rfc/rfc4067.txt- Group and elsewhere for using context transfer to the speed of
../data/rfc/rfc4067.txt: handover of authentication, authorization, and accounting context,
../data/rfc/rfc4067.txt- distributed firewall context, PPP context, and header compression
../data/rfc/rfc4067.txt- context. Because the Working Group was not chartered to develop
../data/rfc/rfc4067.txt- context profile definitions for specific applications, none of the
../data/rfc/rfc4067.txt- documents submitted to Seamoby were accepted as Working Group items.
../data/rfc/rfc4067.txt- At this time, work to develop a context profile definition for RFC
--
../data/rfc/rfc2789.txt- won't be accepted, etc.) vary widely from one MTA to the
../data/rfc/rfc2789.txt- next and cannot be inferred from this variable."
../data/rfc/rfc2789.txt- ::= {mtaEntry 12}
../data/rfc/rfc2789.txt-
../data/rfc/rfc2789.txt- -- MTAs typically group inbound reception, queue storage, and
../data/rfc/rfc2789.txt: -- outbound transmission in some way, rather than accounting for
../data/rfc/rfc2789.txt- -- such operations only across the MTA as a whole. In the most
../data/rfc/rfc2789.txt- -- extreme case separate information will be maintained for each
../data/rfc/rfc2789.txt- -- different entity that receives messages and for each entity
../data/rfc/rfc2789.txt- -- the MTA stores messages for and delivers messages to. Other
../data/rfc/rfc2789.txt- -- MTAs may elect to treat all reception equally, all queue
--
../data/rfc/rfc4590.txt- authenticate itself to a proxy server. Digest Authentication is used
../data/rfc/rfc4590.txt- in other protocols as well.
../data/rfc/rfc4590.txt-
../data/rfc/rfc4590.txt- To simplify the provisioning of users, there is a need to support
../data/rfc/rfc4590.txt- this authentication mechanism within Authentication, Authorization,
../data/rfc/rfc4590.txt: and Accounting (AAA) protocols such as RADIUS [RFC2865] and Diameter
../data/rfc/rfc4590.txt- [RFC3588].
../data/rfc/rfc4590.txt-
../data/rfc/rfc4590.txt-
../data/rfc/rfc4590.txt-
../data/rfc/rfc4590.txt-
--
../data/rfc/rfc4779.txt-
../data/rfc/rfc4779.txt- The BRAS terminates the PPP sessions and provides the subscriber with
../data/rfc/rfc4779.txt- an IPv6 address from the defined pool for that profile. The
../data/rfc/rfc4779.txt- subscriber profile for authorization and authentication can be
../data/rfc/rfc4779.txt- located on the BRAS or on an Authentication, Authorization, and
../data/rfc/rfc4779.txt: Accounting (AAA) server. The Hosts or the Customer Routers have the
../data/rfc/rfc4779.txt- BRAS as their Layer 3 next hop.
../data/rfc/rfc4779.txt-
../data/rfc/rfc4779.txt-
../data/rfc/rfc4779.txt-
../data/rfc/rfc4779.txt-
--
../data/rfc/rfc4779.txt- requests coming from subscribers without CPRs. It has to be enabled
../data/rfc/rfc4779.txt- for PIM-SSM in order to receive joins/leaves from customer routers
../data/rfc/rfc4779.txt- and send joins/leaves to the next hop towards the multicast source
../data/rfc/rfc4779.txt- (Edge Router or the NSP core).
../data/rfc/rfc4779.txt-
../data/rfc/rfc4779.txt: MLD authentication, authorization and accounting are usually
../data/rfc/rfc4779.txt- configured on the Edge Router in order to enable the ISP to control
../data/rfc/rfc4779.txt- the subscriber access of the service and do billing for the content
../data/rfc/rfc4779.txt- provided. Alternative mechanisms that would support these functions
../data/rfc/rfc4779.txt- should be investigated further.
../data/rfc/rfc4779.txt-
--
../data/rfc/rfc4779.txt- requests coming from subscribers without CPRs. It has to be enabled
../data/rfc/rfc4779.txt- for PIM-SSM in order to receive joins/leaves from customer routers
../data/rfc/rfc4779.txt- and send joins/leaves to the next hop towards the multicast source
../data/rfc/rfc4779.txt- (Edge Router or the NSP core).
../data/rfc/rfc4779.txt-
../data/rfc/rfc4779.txt: MLD authentication, authorization, and accounting are usually
../data/rfc/rfc4779.txt- configured on the edge router in order to enable the ISP to control
../data/rfc/rfc4779.txt- the subscriber access of the service and do billing for the content
../data/rfc/rfc4779.txt- provided. Alternative mechanisms that would support these functions
../data/rfc/rfc4779.txt- should be investigated further.
../data/rfc/rfc4779.txt-
--
../data/rfc/rfc4779.txt- to process the requests coming from the IPv6 WLAN Host or WLAN/Access
../data/rfc/rfc4779.txt- Router (if present). The Edge Router has also needs to be enabled
../data/rfc/rfc4779.txt- for PIM-SSM in order to receive joins from IPv6 WLAN Hosts or WLAN/
../data/rfc/rfc4779.txt- Access Router (if present), and send joins towards the SP core.
../data/rfc/rfc4779.txt-
../data/rfc/rfc4779.txt: MLD authentication, authorization, and accounting are usually
../data/rfc/rfc4779.txt- configured on the Edge Router in order to enable the SP to do billing
../data/rfc/rfc4779.txt- for the content services provided. Further investigation should be
../data/rfc/rfc4779.txt- made in finding alternative mechanisms that would support these
../data/rfc/rfc4779.txt- functions.
../data/rfc/rfc4779.txt-
--
../data/rfc/rfc2805.txt- 5.2. Connection Requirements .............................. 7
../data/rfc/rfc2805.txt- 5.3. Media Transformations ................................ 8
../data/rfc/rfc2805.txt- 5.4. Signal/Event Processing and Scripting ................ 9
../data/rfc/rfc2805.txt- 5.5. QoS/CoS .............................................. 10
../data/rfc/rfc2805.txt- 5.6. Test Support ......................................... 11
../data/rfc/rfc2805.txt: 5.7. Accounting ........................................... 11
../data/rfc/rfc2805.txt- 5.8. Signalling Control ................................... 11
../data/rfc/rfc2805.txt- 6. Resource Control .......................................... 12
../data/rfc/rfc2805.txt- 6.1. Resource Status Management ........................... 12
../data/rfc/rfc2805.txt- 6.2. Resource Assignment .................................. 13
../data/rfc/rfc2805.txt- 7. Operational/Management Requirements ....................... 13
--
../data/rfc/rfc2805.txt- for both the originating and terminating ends of the circuit
../data/rfc/rfc2805.txt- connection (2-wire and 4- wire).
../data/rfc/rfc2805.txt-
../data/rfc/rfc2805.txt- b. Specifically support test line operation (e.g. 103, 105, 108).
../data/rfc/rfc2805.txt-
../data/rfc/rfc2805.txt:5.7. Accounting
../data/rfc/rfc2805.txt-
../data/rfc/rfc2805.txt- The protocol must:
../data/rfc/rfc2805.txt-
../data/rfc/rfc2805.txt- a. Support a common identifier to mark resources related to one
../data/rfc/rfc2805.txt- connection.
../data/rfc/rfc2805.txt-
../data/rfc/rfc2805.txt: b. Support collection of specified accounting information from MGs.
../data/rfc/rfc2805.txt-
../data/rfc/rfc2805.txt- c. Provide the mechanism for the MGC to specify that the MG report
../data/rfc/rfc2805.txt: accounting information automatically at end of call, in mid-call
../data/rfc/rfc2805.txt- upon request, at specific time intervals as specified by the MGC
../data/rfc/rfc2805.txt- and at unit usage thresholds as specified by the MGC.
../data/rfc/rfc2805.txt-
../data/rfc/rfc2805.txt- d. Specifically support collection of:
../data/rfc/rfc2805.txt-
--
../data/rfc/rfc3521.txt-
../data/rfc/rfc3521.txt-Abstract
../data/rfc/rfc3521.txt-
../data/rfc/rfc3521.txt- Establishing multimedia streams must take into account requirements
../data/rfc/rfc3521.txt- for end-to-end QoS, authorization of network resource usage and
../data/rfc/rfc3521.txt: accurate accounting for resources used. During session set up,
../data/rfc/rfc3521.txt- policies may be enforced to ensure that the media streams being
../data/rfc/rfc3521.txt- requested lie within the bounds of the service profile established
../data/rfc/rfc3521.txt- for the requesting host. Similarly, when a host requests resources
../data/rfc/rfc3521.txt- to provide a certain QoS for a packet flow, policies may be enforced
../data/rfc/rfc3521.txt- to ensure that the required resources lie within the bounds of the
--
../data/rfc/rfc3521.txt- speed up session setup and still ensure proper authorization is
../data/rfc/rfc3521.txt- performed.
../data/rfc/rfc3521.txt-
../data/rfc/rfc3521.txt- This model does not preclude the possibility that the policy servers
../data/rfc/rfc3521.txt- may communicate at other times for other purposes (e.g., exchange of
../data/rfc/rfc3521.txt: accounting information).
../data/rfc/rfc3521.txt-
../data/rfc/rfc3521.txt-
../data/rfc/rfc3521.txt-
../data/rfc/rfc3521.txt-
../data/rfc/rfc3521.txt-
--
../data/rfc/rfc6983.txt- As stated in [RFC6707], the CDNI Logging interface enables details of
../data/rfc/rfc6983.txt- logs or events to be exchanged between interconnected CDNs.
../data/rfc/rfc6983.txt-
../data/rfc/rfc6983.txt- As discussed in [CDNI-LOGGING], the CDNI logging information can be
../data/rfc/rfc6983.txt- used for multiple purposes, including maintenance/debugging by a
../data/rfc/rfc6983.txt: uCDN, accounting (e.g., for billing or settlement purposes),
../data/rfc/rfc6983.txt- reporting and management of end-user experience (e.g., to the CSP),
../data/rfc/rfc6983.txt- analytics (e.g., by the CSP), and control of content distribution
../data/rfc/rfc6983.txt- policy enforcement (e.g., by the CSP).
../data/rfc/rfc6983.txt-
../data/rfc/rfc6983.txt- The key consideration for HAS with respect to logging is the
--
../data/rfc/rfc6983.txt- f. (Where needed) Logging re-reformatting (e.g., reformatting from
../data/rfc/rfc6983.txt- the CDNI Logging interface format into a log-consuming
../data/rfc/rfc6983.txt- application)
../data/rfc/rfc6983.txt-
../data/rfc/rfc6983.txt- g. Logging consumption/processing (e.g., feed logs into uCDN
../data/rfc/rfc6983.txt: accounting application, feed logs into uCDN reporting system to
../data/rfc/rfc6983.txt- provide per-CSP views, feed logs into debugging tools)
../data/rfc/rfc6983.txt-
../data/rfc/rfc6983.txt- Note that there may be multiple instances of steps [f] and [g]
../data/rfc/rfc6983.txt- running in parallel.
../data/rfc/rfc6983.txt-
--
../data/rfc/rfc8881.txt- The replier compares each received request's sequence ID with the
../data/rfc/rfc8881.txt- last one previously received for that slot ID, to see if the new
../data/rfc/rfc8881.txt- request is:
../data/rfc/rfc8881.txt-
../data/rfc/rfc8881.txt- * A new request, in which the sequence ID is one greater than that
../data/rfc/rfc8881.txt: previously seen in the slot (accounting for sequence wraparound).
../data/rfc/rfc8881.txt- The replier proceeds to execute the new request, and the replier
../data/rfc/rfc8881.txt- MUST increase the slot's sequence ID by one.
../data/rfc/rfc8881.txt-
../data/rfc/rfc8881.txt- * A retransmitted request, in which the sequence ID is equal to that
../data/rfc/rfc8881.txt- currently recorded in the slot. If the original request has
../data/rfc/rfc8881.txt- executed to completion, the replier returns the cached reply. See
../data/rfc/rfc8881.txt- Section 2.10.6.2 for direction on how the replier deals with
../data/rfc/rfc8881.txt- retries of requests that are still in progress.
../data/rfc/rfc8881.txt-
../data/rfc/rfc8881.txt- * A misordered retry, in which the sequence ID is less than
../data/rfc/rfc8881.txt: (accounting for sequence wraparound) that previously seen in the
../data/rfc/rfc8881.txt- slot. The replier MUST return NFS4ERR_SEQ_MISORDERED (as the
../data/rfc/rfc8881.txt- result from SEQUENCE or CB_SEQUENCE).
../data/rfc/rfc8881.txt-
../data/rfc/rfc8881.txt- * A misordered new request, in which the sequence ID is two or more
../data/rfc/rfc8881.txt: than (accounting for sequence wraparound) that previously seen in
../data/rfc/rfc8881.txt- the slot. Note that because the sequence ID MUST wrap around to
../data/rfc/rfc8881.txt- zero once it reaches 0xFFFFFFFF, a misordered new request and a
../data/rfc/rfc8881.txt- misordered retry cannot be distinguished. Thus, the replier MUST
../data/rfc/rfc8881.txt- return NFS4ERR_SEQ_MISORDERED (as the result from SEQUENCE or
../data/rfc/rfc8881.txt- CB_SEQUENCE).
--
../data/rfc/rfc8881.txt- With delegations, a client is able to avoid writing data to the
../data/rfc/rfc8881.txt- server when the CLOSE of a file is serviced. The file close system
../data/rfc/rfc8881.txt- call is the usual point at which the client is notified of a lack of
../data/rfc/rfc8881.txt- stable storage for the modified file data generated by the
../data/rfc/rfc8881.txt- application. At the close, file data is written to the server and,
../data/rfc/rfc8881.txt: through normal accounting, the server is able to determine if the
../data/rfc/rfc8881.txt- available file system space for the data has been exceeded (i.e., the
../data/rfc/rfc8881.txt: server returns NFS4ERR_NOSPC or NFS4ERR_DQUOT). This accounting
../data/rfc/rfc8881.txt- includes quotas. The introduction of delegations requires that an
../data/rfc/rfc8881.txt- alternative method be in place for the same type of communication to
../data/rfc/rfc8881.txt- occur between client and server.
../data/rfc/rfc8881.txt-
../data/rfc/rfc8881.txt- In the delegation response, the server provides either the limit of
--
../data/rfc/rfc8881.txt- (ca_maxoperations(i) - 1), where N is the number of session fore
../data/rfc/rfc8881.txt- channels and ca_maxoperations(i) is the value of the ca_maxoperations
../data/rfc/rfc8881.txt- returned from CREATE_SESSION of the i'th session. The reason for "-
../data/rfc/rfc8881.txt- 1" is to allow for the required SEQUENCE operation. The server MAY
../data/rfc/rfc8881.txt- support a VALID_SEQID_RANGE value larger than the minimum. The
../data/rfc/rfc8881.txt: maximum VALID_SEQID_RANGE is (2^(32) - 2) (accounting for zero not
../data/rfc/rfc8881.txt- being a valid "seqid" value).
../data/rfc/rfc8881.txt-
../data/rfc/rfc8881.txt- If the server finds the "seqid" is zero, the NFS4ERR_BAD_STATEID
../data/rfc/rfc8881.txt- error is returned to the client. The server further validates the
../data/rfc/rfc8881.txt- "seqid" to ensure it is within the range of parallelism,
--
../data/rfc/rfc8881.txt- * that between different named attribute directories or between a
../data/rfc/rfc8881.txt- named attribute directory and an ordinary directory.
../data/rfc/rfc8881.txt-
../data/rfc/rfc8881.txt- * that between byte-ranges of a file system that the file system
../data/rfc/rfc8881.txt- implementation treats as separate (for example, for space
../data/rfc/rfc8881.txt: accounting purposes), and where cross-connection between the byte-
../data/rfc/rfc8881.txt- ranges are not allowed.
../data/rfc/rfc8881.txt-
../data/rfc/rfc8881.txt-15.1.5. State Management Errors
../data/rfc/rfc8881.txt-
../data/rfc/rfc8881.txt- These errors indicate problems with the stateid (or one of the
--
../data/rfc/rfc8881.txt- The server expects value of csa_sequenceid in the arguments to that
../data/rfc/rfc8881.txt- CREATE_SESSION to be to equal the value of the field eir_sequenceid
../data/rfc/rfc8881.txt- that was returned in results of the EXCHANGE_ID that returned the
../data/rfc/rfc8881.txt- unconfirmed client ID. Before the server replies to that EXCHANGE_ID
../data/rfc/rfc8881.txt- operation, it initializes the client ID slot to be equal to
../data/rfc/rfc8881.txt: eir_sequenceid - 1 (accounting for underflow), and records a
../data/rfc/rfc8881.txt- contrived CREATE_SESSION result with a "cached" result of
../data/rfc/rfc8881.txt- NFS4ERR_SEQ_MISORDERED. With the client ID slot thus initialized,
../data/rfc/rfc8881.txt- the processing of the CREATE_SESSION operation is divided into four
../data/rfc/rfc8881.txt- phases:
../data/rfc/rfc8881.txt-
--
../data/rfc/rfc8881.txt-
../data/rfc/rfc8881.txt- 2. Sequence ID processing. If csa_sequenceid is equal to the
../data/rfc/rfc8881.txt- sequence ID in the client ID's slot, then this is a replay of the
../data/rfc/rfc8881.txt- previous CREATE_SESSION request, and the server returns the
../data/rfc/rfc8881.txt- cached result. If csa_sequenceid is not equal to the sequence ID
../data/rfc/rfc8881.txt: in the slot, and is more than one greater (accounting for
../data/rfc/rfc8881.txt- wraparound), then the server returns the error
../data/rfc/rfc8881.txt- NFS4ERR_SEQ_MISORDERED, and does not change the slot. If
../data/rfc/rfc8881.txt: csa_sequenceid is equal to the slot's sequence ID + 1 (accounting
../data/rfc/rfc8881.txt- for wraparound), then the slot's sequence ID is set to
../data/rfc/rfc8881.txt- csa_sequenceid, and the CREATE_SESSION processing goes to the
../data/rfc/rfc8881.txt- next phase. A subsequent new CREATE_SESSION call over the same
../data/rfc/rfc8881.txt- client ID MUST use a csa_sequenceid that is one greater than the
../data/rfc/rfc8881.txt- sequence ID in the slot.
--
../data/rfc/rfc8881.txt- The value of the sa_sequenceid argument relative to the cached
../data/rfc/rfc8881.txt- sequence ID on the slot falls into one of three cases.
../data/rfc/rfc8881.txt-
../data/rfc/rfc8881.txt- * If the difference between sa_sequenceid and the server's cached
../data/rfc/rfc8881.txt- sequence ID at the slot ID is two (2) or more, or if sa_sequenceid
../data/rfc/rfc8881.txt: is less than the cached sequence ID (accounting for wraparound of
../data/rfc/rfc8881.txt- the unsigned sequence ID value), then the server MUST return
../data/rfc/rfc8881.txt- NFS4ERR_SEQ_MISORDERED.
../data/rfc/rfc8881.txt-
../data/rfc/rfc8881.txt- * If sa_sequenceid and the cached sequence ID are the same, this is
../data/rfc/rfc8881.txt- a retry, and the server replies with what is recorded in the reply
../data/rfc/rfc8881.txt- cache. The lease is possibly renewed as described below.
../data/rfc/rfc8881.txt-
../data/rfc/rfc8881.txt: * If sa_sequenceid is one greater (accounting for wraparound) than
../data/rfc/rfc8881.txt- the cached sequence ID, then this is a new request, and the slot's
../data/rfc/rfc8881.txt- sequence ID is incremented. The operations subsequent to
../data/rfc/rfc8881.txt- SEQUENCE, if any, are processed. If there are no other
../data/rfc/rfc8881.txt- operations, the only other effects are to cache the SEQUENCE reply
../data/rfc/rfc8881.txt- in the slot, maintain the session's activity, and possibly renew
--
../data/rfc/rfc8881.txt- void;
../data/rfc/rfc8881.txt- };
../data/rfc/rfc8881.txt-
../data/rfc/rfc8881.txt-20.9.3. DESCRIPTION
../data/rfc/rfc8881.txt-
../data/rfc/rfc8881.txt: The CB_SEQUENCE operation is used to manage operational accounting
../data/rfc/rfc8881.txt- for the backchannel of the session on which a request is sent. The
../data/rfc/rfc8881.txt- contents include the session ID to which this request belongs, the
../data/rfc/rfc8881.txt- slot ID and sequence ID used by the server to implement session
../data/rfc/rfc8881.txt- request control and exactly once semantics, and exchanged slot ID
../data/rfc/rfc8881.txt- maxima that are used to adjust the size of the reply cache. In each
--
../data/rfc/rfc8881.txt- The value of the csa_sequenceid argument relative to the cached
../data/rfc/rfc8881.txt- sequence ID on the slot falls into one of three cases.
../data/rfc/rfc8881.txt-
../data/rfc/rfc8881.txt- * If the difference between csa_sequenceid and the client's cached
../data/rfc/rfc8881.txt- sequence ID at the slot ID is two (2) or more, or if
../data/rfc/rfc8881.txt: csa_sequenceid is less than the cached sequence ID (accounting for
../data/rfc/rfc8881.txt- wraparound of the unsigned sequence ID value), then the client
../data/rfc/rfc8881.txt- MUST return NFS4ERR_SEQ_MISORDERED.
../data/rfc/rfc8881.txt-
../data/rfc/rfc8881.txt- * If csa_sequenceid and the cached sequence ID are the same, this is
../data/rfc/rfc8881.txt- a retry, and the client returns the CB_COMPOUND request's cached
../data/rfc/rfc8881.txt- reply.
../data/rfc/rfc8881.txt-
../data/rfc/rfc8881.txt: * If csa_sequenceid is one greater (accounting for wraparound) than
../data/rfc/rfc8881.txt- the cached sequence ID, then this is a new request, and the slot's
../data/rfc/rfc8881.txt- sequence ID is incremented. The operations subsequent to
../data/rfc/rfc8881.txt- CB_SEQUENCE, if any, are processed. If there are no other
../data/rfc/rfc8881.txt- operations, the only other effects are to cache the CB_SEQUENCE
../data/rfc/rfc8881.txt- reply in the slot, maintain the session's activity, and when the
--
../data/rfc/rfc4580.txt- customers connect through different paths, and as network changes
../data/rfc/rfc4580.txt- occur.
../data/rfc/rfc4580.txt-
../data/rfc/rfc4580.txt- The subscriber-id information allows the service provider to assign/
../data/rfc/rfc4580.txt- activate subscriber-specific actions; e.g., assignment of specific IP
../data/rfc/rfc4580.txt: addresses, prefixes, DNS configuration, trigger accounting, etc.
../data/rfc/rfc4580.txt- This option is de-coupled from the access network's physical
../data/rfc/rfc4580.txt- structure, so a subscriber that moves from one access-point to
../data/rfc/rfc4580.txt- another, for example, would not require reconfiguration at the
../data/rfc/rfc4580.txt- service provider's DHCPv6 servers.
../data/rfc/rfc4580.txt-
--
../data/rfc/rfc7423.txt- 5.5. Session-Id AVP and Session Management . . . . . . . . . . 14
../data/rfc/rfc7423.txt- 5.6. Use of Enumerated Type AVPs . . . . . . . . . . . . . . . 15
../data/rfc/rfc7423.txt- 5.7. Application-Specific Message Routing . . . . . . . . . . 17
../data/rfc/rfc7423.txt- 5.8. Translation Agents . . . . . . . . . . . . . . . . . . . 18
../data/rfc/rfc7423.txt- 5.9. End-to-End Application Capabilities Exchange . . . . . . 18
../data/rfc/rfc7423.txt: 5.10. Diameter Accounting Support . . . . . . . . . . . . . . . 19
../data/rfc/rfc7423.txt- 5.11. Diameter Security Mechanisms . . . . . . . . . . . . . . 21
../data/rfc/rfc7423.txt- 6. Defining Generic Diameter Extensions . . . . . . . . . . . . 21
../data/rfc/rfc7423.txt- 7. Guidelines for Registrations of Diameter Values . . . . . . . 23
../data/rfc/rfc7423.txt- 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
../data/rfc/rfc7423.txt- 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
--
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt-1. Introduction
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt- The Diameter base protocol [RFC6733] is intended to provide an
../data/rfc/rfc7423.txt: Authentication, Authorization, and Accounting (AAA) framework for
../data/rfc/rfc7423.txt- applications such as network access or IP mobility in both local and
../data/rfc/rfc7423.txt- roaming situations. This protocol provides the ability for Diameter
../data/rfc/rfc7423.txt- peers to exchange messages carrying data in the form of Attribute-
../data/rfc/rfc7423.txt- Value Pairs (AVPs).
../data/rfc/rfc7423.txt-
--
../data/rfc/rfc7423.txt- This model is in line with a Diameter node having an application
../data/rfc/rfc7423.txt- layer and a peer-to-peer delivery layer. The Diameter base protocol
../data/rfc/rfc7423.txt- document defines the architecture and behavior of the message
../data/rfc/rfc7423.txt- delivery layer and then provides the framework for designing Diameter
../data/rfc/rfc7423.txt- applications on the application layer. This framework includes
../data/rfc/rfc7423.txt: definitions of application sessions and accounting support (see
../data/rfc/rfc7423.txt- Sections 8 and 9 of [RFC6733]). Accordingly, a Diameter node is seen
../data/rfc/rfc7423.txt- in this document as a single instance of a Diameter message delivery
../data/rfc/rfc7423.txt- layer and one or more Diameter applications using it.
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt- The Diameter base protocol is designed to be extensible and the
--
../data/rfc/rfc7423.txt- (EAP) application [RFC4072] and the Diameter Network Access Server
../data/rfc/rfc7423.txt- application [RFC7155]. When network access authentication using EAP
../data/rfc/rfc7423.txt- is required, the Diameter EAP commands (Diameter-EAP-Request/
../data/rfc/rfc7423.txt- Diameter-EAP-Answer) are used; otherwise, the Diameter Network Access
../data/rfc/rfc7423.txt- Server application will be used. When the Diameter EAP application
../data/rfc/rfc7423.txt: is used, the accounting exchanges defined in the Diameter Network
../data/rfc/rfc7423.txt- Access Server may be used.
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt- However, in general, it is difficult to come to a hard guideline, and
../data/rfc/rfc7423.txt- so a case-by-case study of each application requirement should be
../data/rfc/rfc7423.txt- applied. Before adding or importing a command, application designers
--
../data/rfc/rfc7423.txt- defined for the IP Multimedia Subsystem of 3GPP, e.g., Cx/Dx
../data/rfc/rfc7423.txt- ([TS29.228] and [TS29.229]), Sh ([TS29.328] and [TS29.329]), etc.
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt- Application designers SHOULD try to import existing AVPs and AVP
../data/rfc/rfc7423.txt- values for any newly defined commands. In certain cases where
../data/rfc/rfc7423.txt: accounting will be used, the models described in Section 5.10 SHOULD
../data/rfc/rfc7423.txt- also be considered.
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt- Additional considerations are described in the following sections.
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt-5.2. Defining New Commands
--
../data/rfc/rfc7423.txt- Application Id of the application using those messages. This
../data/rfc/rfc7423.txt- includes the session-level messages defined in the Diameter base
../data/rfc/rfc7423.txt- protocol, i.e., Re-Auth-Request (RAR) / Re-Auth-Answer (RAA),
../data/rfc/rfc7423.txt- Session-Termination-Request (STR) / Session-Termination-Answer (STA),
../data/rfc/rfc7423.txt- Abort-Session-Request (ASR) / Abort-Session-Answer (ASA), and
../data/rfc/rfc7423.txt: possibly Accounting-Request (ACR) / Accounting Answer (ACA) in the
../data/rfc/rfc7423.txt: coupled accounting model; see Section 5.10. Some existing
../data/rfc/rfc7423.txt- specifications do not adhere to this rule for historical reasons.
../data/rfc/rfc7423.txt- However, this guidance SHOULD be followed by new applications to
../data/rfc/rfc7423.txt- avoid routing problems.
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt- When a new application has been allocated with a new Application Id
--
../data/rfc/rfc7423.txt- or proxy agents in the request routing path will be able to release
../data/rfc/rfc7423.txt- the transaction state upon receipt of the corresponding answer,
../data/rfc/rfc7423.txt- avoiding unnecessary failover. Moreover, especially in roaming
../data/rfc/rfc7423.txt- cases, proxy agents in the path must be able to apply local policies
../data/rfc/rfc7423.txt- when receiving the answer from the server during authentication/
../data/rfc/rfc7423.txt: authorization and/or accounting procedures and maintain up-to-date
../data/rfc/rfc7423.txt- session state information by keeping track of all authorized active
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt-Morand, et al. Best Current Practice [Page 17]
--
../data/rfc/rfc7423.txt- with arbitrary functionality. When the added features drastically
../data/rfc/rfc7423.txt- change the Diameter application or when Diameter agents must be
../data/rfc/rfc7423.txt- upgraded to support the new features, a new application SHOULD be
../data/rfc/rfc7423.txt- defined, as recommended in [RFC6733].
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt:5.10. Diameter Accounting Support
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt: Accounting can be treated as an auxiliary application that is used in
../data/rfc/rfc7423.txt: support of other applications. In most cases, accounting support is
../data/rfc/rfc7423.txt- required when defining new applications. This document provides two
../data/rfc/rfc7423.txt: possible models for using accounting:
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt: Split Accounting Model:
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt: In this model, the accounting messages will use the Diameter base
../data/rfc/rfc7423.txt: accounting Application Id (value of 3). The design implication
../data/rfc/rfc7423.txt: for this is that the accounting is treated as an independent
../data/rfc/rfc7423.txt- application, especially for Diameter routing. This means that
../data/rfc/rfc7423.txt: accounting commands emanating from an application may be routed
../data/rfc/rfc7423.txt- separately from the rest of the other application messages. This
../data/rfc/rfc7423.txt: may also imply that the messages end up in a central accounting
../data/rfc/rfc7423.txt: server. A split accounting model is a good design choice when:
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt: * The application itself does not define its own accounting
../data/rfc/rfc7423.txt- commands.
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt- * The overall system architecture permits the use of centralized
../data/rfc/rfc7423.txt: accounting for one or more Diameter applications.
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt: Centralizing accounting may have advantages, but there are also
../data/rfc/rfc7423.txt: drawbacks. The model assumes that the accounting server can
../data/rfc/rfc7423.txt: differentiate received accounting messages. Since the received
../data/rfc/rfc7423.txt: accounting messages can be for any application and/or service, the
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt-Morand, et al. Best Current Practice [Page 19]
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt-RFC 7423 Diameter Applications Design Guidelines November 2014
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt: accounting server MUST have a method to match accounting messages
../data/rfc/rfc7423.txt- with applications and/or services being accounted for. This may
../data/rfc/rfc7423.txt- mean defining new AVPs; checking the presence, absence, or
../data/rfc/rfc7423.txt- contents of existing AVPs; or checking the contents of the
../data/rfc/rfc7423.txt: accounting record itself. One of these means could be to insert
../data/rfc/rfc7423.txt: into the request sent to the accounting server an
../data/rfc/rfc7423.txt- Auth-Application-Id AVP containing the identifier of the
../data/rfc/rfc7423.txt: application for which the accounting request is sent. But in
../data/rfc/rfc7423.txt- general, there is no clean and generic scheme for sorting these
../data/rfc/rfc7423.txt- messages. Therefore, this model SHOULD NOT be used when all
../data/rfc/rfc7423.txt: received accounting messages cannot be clearly identified and
../data/rfc/rfc7423.txt: sorted. For most cases, the use of the Coupled Accounting Model
../data/rfc/rfc7423.txt- is RECOMMENDED.
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt: Coupled Accounting Model:
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt: In this model, the accounting messages will use the Application Id
../data/rfc/rfc7423.txt: of the application using the accounting service. The design
../data/rfc/rfc7423.txt: implication for this is that the accounting messages are tightly
../data/rfc/rfc7423.txt: coupled with the application itself, meaning that accounting
../data/rfc/rfc7423.txt- messages will be routed like the other application messages. It
../data/rfc/rfc7423.txt- would then be the responsibility of the application server
../data/rfc/rfc7423.txt- (application entity receiving the ACR message) to send the
../data/rfc/rfc7423.txt: accounting records carried by the accounting messages to the
../data/rfc/rfc7423.txt: proper accounting server. The application server is also
../data/rfc/rfc7423.txt- responsible for formulating a proper response (ACA). A coupled
../data/rfc/rfc7423.txt: accounting model is a good design choice when:
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt- * The system architecture or deployment does not provide an
../data/rfc/rfc7423.txt: accounting server that supports Diameter. Consequently, the
../data/rfc/rfc7423.txt- application server MUST be provisioned to use a different
../data/rfc/rfc7423.txt: protocol to access the accounting server, e.g., via the
../data/rfc/rfc7423.txt- Lightweight Directory Access Protocol (LDAP), SOAP, etc. This
../data/rfc/rfc7423.txt: case includes the support of older accounting systems that are
../data/rfc/rfc7423.txt- not Diameter aware.
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt- * The system architecture or deployment requires that the
../data/rfc/rfc7423.txt: accounting service for the specific application should be
../data/rfc/rfc7423.txt- handled by the application itself.
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt- In all cases above, there will generally be no direct Diameter
../data/rfc/rfc7423.txt: access to the accounting server.
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt: These models provide a basis for using accounting messages.
../data/rfc/rfc7423.txt- Application designers may obviously deviate from these models
../data/rfc/rfc7423.txt- provided that the factors being addressed here have also been taken
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt-
--
../data/rfc/rfc7423.txt-RFC 7423 Diameter Applications Design Guidelines November 2014
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt- into account. As a general recommendation, application designers
../data/rfc/rfc7423.txt- SHOULD NOT define a new set of commands to carry application-specific
../data/rfc/rfc7423.txt: accounting records.
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt-5.11. Diameter Security Mechanisms
../data/rfc/rfc7423.txt-
../data/rfc/rfc7423.txt- As specified in [RFC6733], the Diameter message exchange SHOULD be
../data/rfc/rfc7423.txt- secured between neighboring Diameter peers using Transport Layer
--
../data/rfc/rfc5121.txt- serves multiple IPv6 hosts may be the end point of the connection.
../data/rfc/rfc5121.txt- Hence, one or more /64 prefixes SHOULD be assigned to a link. The
../data/rfc/rfc5121.txt- prefixes are advertised with the on-link (L-bit) flag set as
../data/rfc/rfc5121.txt- specified in [RFC4861]. The size and number of the prefixes are a
../data/rfc/rfc5121.txt- configuration issue. Also, Dynamic Host Configuration Protocol
../data/rfc/rfc5121.txt: (DHCP) or Authentication, Authorization, and Accounting (AAA)-based
../data/rfc/rfc5121.txt- prefix delegation MAY be used to provide one or more prefixes to MS
../data/rfc/rfc5121.txt- for an AR connected over 802.16. The other properties of the
../data/rfc/rfc5121.txt- prefixes are also dealt with via configuration.
../data/rfc/rfc5121.txt-
../data/rfc/rfc5121.txt-8. Router Discovery
--
../data/rfc/rfc5998.txt- requirements of many deployment scenarios. By using EAP, IKEv2 can
../data/rfc/rfc5998.txt- leverage existing authentication infrastructure and credential
../data/rfc/rfc5998.txt- databases, since EAP allows users to choose a method suitable for
../data/rfc/rfc5998.txt- existing credentials, and also makes separation of the IKEv2
../data/rfc/rfc5998.txt- responder (VPN gateway) from the EAP authentication endpoint (backend
../data/rfc/rfc5998.txt: Authentication, Authorization, and Accounting (AAA) server) easier.
../data/rfc/rfc5998.txt-
../data/rfc/rfc5998.txt- Some older EAP methods are designed for unilateral authentication
../data/rfc/rfc5998.txt- only (that is, EAP peer to EAP server). These methods are used in
../data/rfc/rfc5998.txt- conjunction with IKEv2 public-key-based authentication of the
../data/rfc/rfc5998.txt- responder to the initiator. It is expected that this approach is
--
../data/rfc/rfc677.txt-This RFC is a working paper on the problem of maintaining duplicated
../data/rfc/rfc677.txt-databases in an ARPA-like network. It briefly discusses the general
../data/rfc/rfc677.txt-duplicate database problem, and then outlines in some detail a solution
../data/rfc/rfc677.txt-for a particular type of duplicate database. The concepts developed
../data/rfc/rfc677.txt-here were used in the design of the User Identification Database for the
../data/rfc/rfc677.txt:TIP user authentication and accounting system. We believe that these
../data/rfc/rfc677.txt-concepts are generally applicable to distributed database problems.
../data/rfc/rfc677.txt-
../data/rfc/rfc677.txt-
../data/rfc/rfc677.txt-
../data/rfc/rfc677.txt-
--
../data/rfc/rfc677.txt-important motivations are:
../data/rfc/rfc677.txt-
../data/rfc/rfc677.txt- - to increase reliability of data access.
../data/rfc/rfc677.txt-
../data/rfc/rfc677.txt- The accessibility of critical data can be increased by redundantly
../data/rfc/rfc677.txt: maintaining it. The database used for TIP login and accounting is
../data/rfc/rfc677.txt- redundantly distributed to achieve highly reliable access.
../data/rfc/rfc677.txt-
../data/rfc/rfc677.txt- - to insure efficiency of data access.
../data/rfc/rfc677.txt-
../data/rfc/rfc677.txt- Data can be more quickly and efficiently accessed when it is "near"
--
../data/rfc/rfc1539.txt-
../data/rfc/rfc1539.txt- For those who could not attend a meeting but would like a copy of the
../data/rfc/rfc1539.txt- Proceedings send a check for $35 (made payable to CNRI) to:
../data/rfc/rfc1539.txt-
../data/rfc/rfc1539.txt- Corporation for National Research Initiatives
../data/rfc/rfc1539.txt: Attn: Accounting Department - IETF Proceedings
../data/rfc/rfc1539.txt- 1895 Preston White Drive, Suite 100
../data/rfc/rfc1539.txt- Reston, VA 22091
../data/rfc/rfc1539.txt-
../data/rfc/rfc1539.txt- Please indicate which meeting Proceedings you would like to receive
../data/rfc/rfc1539.txt- by specifying the meeting date (e.g., July 1993) or meeting number
--
../data/rfc/rfc5181.txt- [IEEE802.16e].
../data/rfc/rfc5181.txt-
../data/rfc/rfc5181.txt-2.5. IPv6 Security
../data/rfc/rfc5181.txt-
../data/rfc/rfc5181.txt- When initiating the connection, an MS is authenticated by the
../data/rfc/rfc5181.txt: Authentication, Authorization, and Accounting (AAA) server located at
../data/rfc/rfc5181.txt- its service provider network. To achieve that, the MS and the BS use
../data/rfc/rfc5181.txt- Privacy Key Management [IEEE802.16],[IEEE802.16e], while the BS
../data/rfc/rfc5181.txt- communicates with the AAA server using a AAA protocol. Once the MS
../data/rfc/rfc5181.txt- is authenticated with the AAA server, it can associate successfully
../data/rfc/rfc5181.txt- with the BS and acquire an IPv6 address through stateless auto-
--
../data/rfc/rfc2904.txt- variety of different authorization needs.
../data/rfc/rfc2904.txt-
../data/rfc/rfc2904.txt- We expect that this work may be extended in the future to a more
../data/rfc/rfc2904.txt- comprehensive model and that the scheme described here will be
../data/rfc/rfc2904.txt- incorporated into a framework that includes authentication,
../data/rfc/rfc2904.txt: accounting and auditing. We have referenced a number of
../data/rfc/rfc2904.txt- authorization sources, but also recognize that there may be some that
../data/rfc/rfc2904.txt- we have missed and that should be included. Please notify one of the
../data/rfc/rfc2904.txt- authors of any such oversight so it can be corrected in a future
../data/rfc/rfc2904.txt- revision.
../data/rfc/rfc2904.txt-
../data/rfc/rfc2904.txt- In general, it is assumed that the parties who are participating in
../data/rfc/rfc2904.txt- the authorization process have already gone through an authentication
../data/rfc/rfc2904.txt- phase. The authentication method used by those parties is outside
../data/rfc/rfc2904.txt- the scope of this document except to the extent that it influences
../data/rfc/rfc2904.txt- the requirements found in a subsequent authorization process.
../data/rfc/rfc2904.txt: Likewise, accounting requirements are outside the scope of this
../data/rfc/rfc2904.txt: document other than recording accounting data or establishing trust
../data/rfc/rfc2904.txt- relationships during an authorization that will facilitate a
../data/rfc/rfc2904.txt: subsequent accounting phase.
../data/rfc/rfc2904.txt-
../data/rfc/rfc2904.txt- The work for this memo was done by a group that originally was the
../data/rfc/rfc2904.txt- Authorization subgroup of the AAA Working Group of the IETF. When
../data/rfc/rfc2904.txt- the charter of the AAA working group was changed to focus on MobileIP
../data/rfc/rfc2904.txt- and NAS requirements, the AAAarch Research Group was chartered within
--
../data/rfc/rfc2904.txt-
../data/rfc/rfc2904.txt- This requirement has been clearly documented in [10], which describes
../data/rfc/rfc2904.txt- many current weaknesses of the RADIUS protocol [11] in roaming
../data/rfc/rfc2904.txt- networks since RADIUS does not provide such functionality. One
../data/rfc/rfc2904.txt- well-known attack is the ability for the intermediate nodes to modify
../data/rfc/rfc2904.txt: critical accounting information, such as a session time.
../data/rfc/rfc2904.txt-
../data/rfc/rfc2904.txt- Most popular security protocols (e.g. IPSec, SSL, etc.) do not
../data/rfc/rfc2904.txt- provide the ability to secure a portion of the payload. Therefore, it
../data/rfc/rfc2904.txt- may be necessary for the AAA protocol to implement its own security
../data/rfc/rfc2904.txt- extensions to provide end-to-end security.
--
../data/rfc/rfc2904.txt-
../data/rfc/rfc2904.txt- Furthermore, it should be possible for the Brokers to allow end-to-
../data/rfc/rfc2904.txt- end (direct) authentication and authorization. This can be done as
../data/rfc/rfc2904.txt- follows. The User Home Organization generates a ticket which is
../data/rfc/rfc2904.txt- signed using the UHO's private key. The ticket is carried in the
../data/rfc/rfc2904.txt: accounting messages. The accounting messages must flow through the
../data/rfc/rfc2904.txt- Broker since the Broker is acting as the settlement agent and
../data/rfc/rfc2904.txt- requires this information. There are Brokers that will require to be
../data/rfc/rfc2904.txt- in the authentication and authorization path as well since they will
../data/rfc/rfc2904.txt- use this information to detect fraudulent activity, so the above
../data/rfc/rfc2904.txt- should be optional.
--
../data/rfc/rfc4881.txt- distance (in terms of delay) from the nFA. The time required for the
../data/rfc/rfc4881.txt- handoff procedure to complete can be reduced by using a closer local
../data/rfc/rfc4881.txt- HA, called Gateway Foreign Agent (GFA) in [11]. However,
../data/rfc/rfc4881.txt- implementation of [11] is not required by PRE-REGISTRATION. PRE-
../data/rfc/rfc4881.txt- REGISTRATION also supports movement where a new Authentication,
../data/rfc/rfc4881.txt: Authorization, and Accounting (AAA) transaction must occur to
../data/rfc/rfc4881.txt- authenticate the MN with a new domain.
../data/rfc/rfc4881.txt-
../data/rfc/rfc4881.txt-
../data/rfc/rfc4881.txt-
../data/rfc/rfc4881.txt-
--
../data/rfc/rfc3945.txt- configured on the advertising LSR, others may be obtained from other
../data/rfc/rfc3945.txt- LSRs by means of some protocol, and yet others may be deduced from
../data/rfc/rfc3945.txt- the component(s) of the TE link.
../data/rfc/rfc3945.txt-
../data/rfc/rfc3945.txt- An important TE property of a TE link is related to the bandwidth
../data/rfc/rfc3945.txt: accounting for that link. GMPLS will define different accounting
../data/rfc/rfc3945.txt- rules for different non-PSC layers. Generic bandwidth attributes are
../data/rfc/rfc3945.txt- however defined by the TE routing extensions and by GMPLS, such as
../data/rfc/rfc3945.txt- the unreserved bandwidth, the maximum reservable bandwidth and the
../data/rfc/rfc3945.txt- maximum LSP bandwidth.
../data/rfc/rfc3945.txt-
../data/rfc/rfc3945.txt- It is expected in a dynamic environment to have frequent changes of
../data/rfc/rfc3945.txt: bandwidth accounting information. A flexible policy for triggering
../data/rfc/rfc3945.txt- link state updates based on bandwidth thresholds and link-dampening
../data/rfc/rfc3945.txt- mechanism can be implemented.
../data/rfc/rfc3945.txt-
../data/rfc/rfc3945.txt- TE properties associated with a link should also capture protection
../data/rfc/rfc3945.txt- and restoration related characteristics. For instance, shared
--
../data/rfc/rfc610.txt- recovery systems, through internal consistency checks),
../data/rfc/rfc610.txt- (5) _regulating_access_, to protect the databases, the system, and
../data/rfc/rfc610.txt- the privacy of users.
../data/rfc/rfc610.txt-
../data/rfc/rfc610.txt-These are the major data-related functions of the datacomputer; while
../data/rfc/rfc610.txt:the system will ultimately provide other services (such as accounting
../data/rfc/rfc610.txt-for use, monitoring performance) these are really auxiliary and common
../data/rfc/rfc610.txt-to all service facilities.
../data/rfc/rfc610.txt-
../data/rfc/rfc610.txt-This section presents global considerations for the design of
../data/rfc/rfc610.txt-datalanguage, based on our observations about the problem and the
--
../data/rfc/rfc943.txt- 1-149 Unassigned [JBP]
../data/rfc/rfc943.txt- 150 Xerox NS IDP [114,LLG]
../data/rfc/rfc943.txt- 151 Unassigned [JBP]
../data/rfc/rfc943.txt- 152 PARC Universal Protocol [12,HGM]
../data/rfc/rfc943.txt- 153 TIP Status Reporting [JGH]
../data/rfc/rfc943.txt: 154 TIP Accounting [JGH]
../data/rfc/rfc943.txt- 155 Internet Protocol [regular] [35,80,JBP]
../data/rfc/rfc943.txt- 156-158 Internet Protocol [experimental] [35,80,JBP]
../data/rfc/rfc943.txt- 159 Figleaf Link [JBW1]
../data/rfc/rfc943.txt- 160-194 Unassigned [JBP]
../data/rfc/rfc943.txt- 195 ISO-IP [116,RXM]
--
../data/rfc/rfc3543.txt- the binding to expire. This also applies to the case in which a
../data/rfc/rfc3543.txt- mobile node roams away from a foreign agent to another foreign
../data/rfc/rfc3543.txt- agent. Notification to the previous foreign agent would allow it
../data/rfc/rfc3543.txt- to reclaim resources.
../data/rfc/rfc3543.txt-
../data/rfc/rfc3543.txt: 2. Accurate accounting. This has a favorable impact on resolving
../data/rfc/rfc3543.txt: accounting issues with respect to the length of mobility bindings
../data/rfc/rfc3543.txt- in both domains, as the actual end of the registration is relayed.
../data/rfc/rfc3543.txt-
../data/rfc/rfc3543.txt- 3. Earlier adoption of domain policy changes with regards to services
../data/rfc/rfc3543.txt- offered/required of a Mobile IP binding. For example, the home
../data/rfc/rfc3543.txt- domain may now require reverse tunnels [C], yet there are existing
--
../data/rfc/rfc3543.txt-
../data/rfc/rfc3543.txt-
../data/rfc/rfc3543.txt-8.2. Informational References (Alphabetical)
../data/rfc/rfc3543.txt-
../data/rfc/rfc3543.txt- [A] Glass, S., Hiller, T., Jacobs, S. and C. Perkins, "Mobile IP
../data/rfc/rfc3543.txt: Authentication, Authorization, and Accounting Requirements", RFC
../data/rfc/rfc3543.txt- 2977, October 2000.
../data/rfc/rfc3543.txt-
../data/rfc/rfc3543.txt- [B] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P.,
../data/rfc/rfc3543.txt- Shiino, H., Walsh, P., Zorn, G., Dommety, G., Perkins, C., Patil,
../data/rfc/rfc3543.txt- B., Mitton, D., Manning, S., Beadles, M., Chen, X., Sivalingham,
--
../data/rfc/rfc4313.txt- server and to request verification. The SV server verifies the
../data/rfc/rfc4313.txt- user's identity and returns the result, including the necessary login
../data/rfc/rfc4313.txt- credentials, to the phone via SPEECHSC. The IP Phone may use the
../data/rfc/rfc4313.txt- identity directly to identify the user in outgoing calls, to fetch
../data/rfc/rfc4313.txt- the user's preferences from a configuration server, or to request
../data/rfc/rfc4313.txt: authorization from an Authentication, Authorization, and Accounting
../data/rfc/rfc4313.txt- (AAA) server, in any combination. Since this example uses SPEECHSC
../data/rfc/rfc4313.txt- to perform a security-related function, be sure to note the
../data/rfc/rfc4313.txt- associated material in Section 9.
../data/rfc/rfc4313.txt-
../data/rfc/rfc4313.txt-3. General Requirements
--
../data/rfc/rfc2400.txt-MAPOS-SONET Multiple Access Protocol over SONET/SDH Version 1 2171
../data/rfc/rfc2400.txt-RWHOIS Referral Whois Protocol 2167
../data/rfc/rfc2400.txt-PPP-EXT PPP Vendor Extensions 2153
../data/rfc/rfc2400.txt-UTF-7 UTF-7 2152
../data/rfc/rfc2400.txt-CAST-128 CAST-128 Encryption Algorithm 2144
../data/rfc/rfc2400.txt:RADIUS-ACC RADIUS Accounting 2139
../data/rfc/rfc2400.txt-DLSCAP Data Link Switching Client Access Protocol 2114
../data/rfc/rfc2400.txt-PNG Portable Network Graphics Version 1.0 2083
../data/rfc/rfc2400.txt-RC5 RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms 2040
../data/rfc/rfc2400.txt-SNTP Simple Network Time Protocol v4 for IPv4, IPv6 and OSI 2030
../data/rfc/rfc2400.txt-PGP-MEF PGP Message Exchange Formats 1991
--
../data/rfc/rfc5539.txt- The security considerations described throughout [RFC5246] and
../data/rfc/rfc5539.txt- [RFC4741] apply here as well.
../data/rfc/rfc5539.txt-
../data/rfc/rfc5539.txt- This document in its current version does not support third-party
../data/rfc/rfc5539.txt- authentication (e.g., backend Authentication, Authorization, and
../data/rfc/rfc5539.txt: Accounting (AAA) servers) due to the fact that TLS does not specify
../data/rfc/rfc5539.txt- this way of authentication and that NETCONF depends on the transport
../data/rfc/rfc5539.txt- protocol for the authentication service. If third-party
../data/rfc/rfc5539.txt- authentication is needed, BEEP or SSH transport can be used.
../data/rfc/rfc5539.txt-
../data/rfc/rfc5539.txt-
--
../data/rfc/rfc1125.txt- a single network protocol can vary greatly as to their efficiency
../data/rfc/rfc1125.txt- [8]. We can not assume control over implementation across AD
../data/rfc/rfc1125.txt- boundaries. Feedback mechanisms such as metering (and charging in
../data/rfc/rfc1125.txt- some cases) would introduce a concrete incentive for ADs to employ
../data/rfc/rfc1125.txt- efficient and correct implementations. PR should allow an AD to
../data/rfc/rfc1125.txt: advertise and apply such accounting measures to inter-AD traffic.
../data/rfc/rfc1125.txt-
../data/rfc/rfc1125.txt- In summary, the lack of global authority, the need to support network
../data/rfc/rfc1125.txt- resource sharing as well as network interconnection, the complex and
../data/rfc/rfc1125.txt- dynamic mapping of users to ADs and rights, and the need for
../data/rfc/rfc1125.txt- accountability across ADs, are characteristics of inter-AD
--
../data/rfc/rfc1125.txt- sample policy statements should not} be interpreted as agency policy,
../data/rfc/rfc1125.txt- they are provided here only as examples.
../data/rfc/rfc1125.txt-
../data/rfc/rfc1125.txt- Internet policies fall into two classes, access and charging. Access
../data/rfc/rfc1125.txt- policies specify who can use resources and under what conditions.
../data/rfc/rfc1125.txt: Charging policies specify the metering, accounting, and billing
../data/rfc/rfc1125.txt- implemented by a particular AD.
../data/rfc/rfc1125.txt-
../data/rfc/rfc1125.txt-6.1 TAXONOMY OF ACCESS POLICIES
../data/rfc/rfc1125.txt-
../data/rfc/rfc1125.txt- We have identified the following types of access policies that ADs
--
../data/rfc/rfc1125.txt-6.2 TAXONOMY OF CHARGING POLICIES
../data/rfc/rfc1125.txt-
../data/rfc/rfc1125.txt- Stub and transit charging policies may specify the following
../data/rfc/rfc1125.txt- parameters:
../data/rfc/rfc1125.txt-
../data/rfc/rfc1125.txt: * UNIT OF ACCOUNTING (e.g., dollars or credits).
../data/rfc/rfc1125.txt- * BASIS FOR CHARGING (e.g., per Kbyte or per Kpkt).
../data/rfc/rfc1125.txt- * ACTUAL CHARGES (e.g., actual numbers such as $.50/Mbyte).
../data/rfc/rfc1125.txt- * WHO IS CHARGED OR PAID (e.g., originator of packet,
../data/rfc/rfc1125.txt- immediate neighbor from whom packet was received, destination
../data/rfc/rfc1125.txt- of packet, a third party collection agent).
--
../data/rfc/rfc1125.txt- available BW by non-nasa Federal agencies is below n%. NOTE THAT this
../data/rfc/rfc1125.txt- non-interference policy type needs some more work in terms of
../data/rfc/rfc1125.txt- integrating it into the routing algorithms. See Section 7.
../data/rfc/rfc1125.txt-
../data/rfc/rfc1125.txt- [NASA2: (*,{F},*)(*,{F},*){research,support}
../data/rfc/rfc1125.txt: {per-packet accounting, limited to n% of available BW}{}]
../data/rfc/rfc1125.txt-
../data/rfc/rfc1125.txt- 3. NASA will carry commercial traffic to federal and regional and
../data/rfc/rfc1125.txt- university ADs for nasa research or support. But it will not allow
../data/rfc/rfc1125.txt- transit. The particular entry AD is not important.
../data/rfc/rfc1125.txt-
--
../data/rfc/rfc1125.txt- commercial carriers to provide increasingly higher level and enhanced
../data/rfc/rfc1125.txt- services such as high speed packet switched backbone services.
../data/rfc/rfc1125.txt- Because such services are not yet part of the Research Internet
../data/rfc/rfc1125.txt- infrastructure there exist no policy statements.
../data/rfc/rfc1125.txt-
../data/rfc/rfc1125.txt: Charging and accounting are certain to be an important policy type in
../data/rfc/rfc1125.txt- this context. Moreover, we anticipate the long haul services market
../data/rfc/rfc1125.txt- to be highly competitive. This implies that competing service
../data/rfc/rfc1125.txt- providers will engage in significant gaming in terms of packaging and
../data/rfc/rfc1125.txt- pricing of services. Consequently, the ability to express varied and
../data/rfc/rfc1125.txt- dynamic charging policies will be critical for these ADs.
--
../data/rfc/rfc471.txt- (an ARPANET Executive protocol?)
../data/rfc/rfc471.txt-
../data/rfc/rfc471.txt-3. To what extent can the conversational user interface be standardized
../data/rfc/rfc471.txt- in the user processes? (an ARPANET Executive language?)
../data/rfc/rfc471.txt-
../data/rfc/rfc471.txt:4. How can access authentication and accounting procedures be modified
../data/rfc/rfc471.txt- to permit a user to "login" only once, yet use resources at many
../data/rfc/rfc471.txt- Host sites?
../data/rfc/rfc471.txt-
../data/rfc/rfc471.txt-If you are interested in discussing these and related issues forward
../data/rfc/rfc471.txt-your name to Bob Thomas (BTHOMAS @BBN-TENEX), Bolt Beranek and Newman,
--
../data/rfc/rfc6867.txt- outage, device suspension, or a temporary move out of range. This is
../data/rfc/rfc6867.txt- similar to the session resumption mechanism described in [RFC5723].
../data/rfc/rfc6867.txt- One exception being that instead of a ticket stored by the client,
../data/rfc/rfc6867.txt- the re-authentication Master Session Key (rMSK) (see Section 4.6 of
../data/rfc/rfc6867.txt- [RFC6696]) is used as the session key stored on both the client and
../data/rfc/rfc6867.txt: the Authentication, Authorization, and Accounting (AAA) server.
../data/rfc/rfc6867.txt-
../data/rfc/rfc6867.txt-
../data/rfc/rfc6867.txt-
../data/rfc/rfc6867.txt-
../data/rfc/rfc6867.txt-
--
../data/rfc/rfc3435.txt- minimum, unique within the collection of Call Agents that control the
../data/rfc/rfc3435.txt- same gateways. From the gateway's perspective, the Call identifier
../data/rfc/rfc3435.txt- is thus unique. When a Call Agent builds several connections that
../data/rfc/rfc3435.txt- pertain to the same call, either on the same gateway or in different
../data/rfc/rfc3435.txt- gateways, these connections that belong to the same call should share
../data/rfc/rfc3435.txt: the same call-id. This identifier can then be used by accounting or
../data/rfc/rfc3435.txt- management procedures, which are outside the scope of MGCP.
../data/rfc/rfc3435.txt-
../data/rfc/rfc3435.txt-2.1.3.2 Names of Connections
../data/rfc/rfc3435.txt-
../data/rfc/rfc3435.txt- Connection identifiers are created by the gateway when it is
--
../data/rfc/rfc3435.txt- this connection belongs. This parameter SHOULD, at a minimum, be
../data/rfc/rfc3435.txt- unique within the collection of Call Agents that control the same
../data/rfc/rfc3435.txt- gateways. Connections that belong to the same call SHOULD share the
../data/rfc/rfc3435.txt- same call-id. The call-id has little semantic meaning in the
../data/rfc/rfc3435.txt- protocol; however it can be used to identify calls for reporting and
../data/rfc/rfc3435.txt: accounting purposes. It does not affect the handling of connections
../data/rfc/rfc3435.txt- by the gateway.
../data/rfc/rfc3435.txt-
../data/rfc/rfc3435.txt- EndpointId is the identifier for the connection endpoint in the
../data/rfc/rfc3435.txt- gateway where CreateConnection executes. The EndpointId can be
../data/rfc/rfc3435.txt- fully-specified by assigning a value to the parameter EndpointId in
--
../data/rfc/rfc6653.txt- router offloading delegation of prefixes and release tasks to a
../data/rfc/rfc6653.txt- DHCPv6 server. The access router first requests a prefix for an
../data/rfc/rfc6653.txt- incoming mobile node from the DHCPv6 server. The access router may
../data/rfc/rfc6653.txt- next do stateless or stateful address allocation to the mobile node,
../data/rfc/rfc6653.txt- e.g., with a Router Advertisement or using DHCP. We also describe
../data/rfc/rfc6653.txt: prefix management using Authentication, Authorization, and Accounting
../data/rfc/rfc6653.txt- (AAA) servers.
../data/rfc/rfc6653.txt-
../data/rfc/rfc6653.txt-Status of This Memo
../data/rfc/rfc6653.txt-
../data/rfc/rfc6653.txt- This document is not an Internet Standards Track specification; it is
--
../data/rfc/rfc6653.txt- MNs and is in charge of address/prefix management.
../data/rfc/rfc6653.txt-
../data/rfc/rfc6653.txt- The AR is connected to an IP network that is owned by the operator;
../data/rfc/rfc6653.txt- this network is connected to the public Internet via a border router.
../data/rfc/rfc6653.txt- The network contains servers for subscriber management, including
../data/rfc/rfc6653.txt: Quality of Service, billing, and accounting, as well as a Dynamic
../data/rfc/rfc6653.txt- Host Configuration Protocol (DHCP) server [RFC6342].
../data/rfc/rfc6653.txt-
../data/rfc/rfc6653.txt- With IPv6 addressing, because mobile network links are point-to-point
../data/rfc/rfc6653.txt- (P2P), the per-MN interface prefix model is used [RFC3314] [RFC3316].
../data/rfc/rfc6653.txt- In the per-MN interface prefix model, prefix management is an issue.
--
../data/rfc/rfc6653.txt-
../data/rfc/rfc6653.txt-2. Terminology and Acronyms
../data/rfc/rfc6653.txt-
../data/rfc/rfc6653.txt- 3GPP - 3rd Generation Partnership Project
../data/rfc/rfc6653.txt-
../data/rfc/rfc6653.txt: AAA - Authentication, Authorization, and Accounting
../data/rfc/rfc6653.txt-
../data/rfc/rfc6653.txt- AR - Access Router
../data/rfc/rfc6653.txt-
../data/rfc/rfc6653.txt- BS - Base Station
../data/rfc/rfc6653.txt-
--
../data/rfc/rfc4962.txt-BCP: 132 B. Aboba
../data/rfc/rfc4962.txt-Category: Best Current Practice Microsoft
../data/rfc/rfc4962.txt- July 2007
../data/rfc/rfc4962.txt-
../data/rfc/rfc4962.txt-
../data/rfc/rfc4962.txt: Guidance for Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc4962.txt- Key Management
../data/rfc/rfc4962.txt-
../data/rfc/rfc4962.txt-Status of This Memo
../data/rfc/rfc4962.txt-
../data/rfc/rfc4962.txt- This document specifies an Internet Best Current Practices for the
--
../data/rfc/rfc4962.txt- Copyright (C) The IETF Trust (2007).
../data/rfc/rfc4962.txt-
../data/rfc/rfc4962.txt-Abstract
../data/rfc/rfc4962.txt-
../data/rfc/rfc4962.txt- This document provides guidance to designers of Authentication,
../data/rfc/rfc4962.txt: Authorization, and Accounting (AAA) key management protocols. The
../data/rfc/rfc4962.txt- guidance is also useful to designers of systems and solutions that
../data/rfc/rfc4962.txt- include AAA key management protocols. Given the complexity and
../data/rfc/rfc4962.txt- difficulty in designing secure, long-lasting key management
../data/rfc/rfc4962.txt- algorithms and protocols by experts in the field, it is almost
../data/rfc/rfc4962.txt- certainly inappropriate for IETF working groups without deep
../data/rfc/rfc4962.txt- expertise in the area to be designing their own key management
../data/rfc/rfc4962.txt- algorithms and protocols based on Authentication, Authorization, and
../data/rfc/rfc4962.txt: Accounting (AAA) protocols. The guidelines in this document apply to
../data/rfc/rfc4962.txt- documents requesting publication as IETF RFCs. Further, these
../data/rfc/rfc4962.txt- guidelines will be useful to other standards development
../data/rfc/rfc4962.txt- organizations (SDOs) that specify AAA key management.
../data/rfc/rfc4962.txt-
../data/rfc/rfc4962.txt-
--
../data/rfc/rfc4962.txt- Given the complexity and difficulty in designing secure, long-lasting
../data/rfc/rfc4962.txt- key management algorithms and protocols by experts in the field, it
../data/rfc/rfc4962.txt- is almost certainly inappropriate for IETF working groups without
../data/rfc/rfc4962.txt- deep expertise in the area to be designing their own key management
../data/rfc/rfc4962.txt- algorithms and protocols based on Authentication, Authorization and
../data/rfc/rfc4962.txt: Accounting (AAA) protocols. These guidelines apply to documents
../data/rfc/rfc4962.txt- requesting publication as IETF RFCs. Further, these guidelines will
../data/rfc/rfc4962.txt- be useful to other standards development organizations (SDOs) that
../data/rfc/rfc4962.txt- specify AAA key management that depends on IETF specifications for
../data/rfc/rfc4962.txt- protocols such as Extensible Authentication Protocol (EAP) [RFC3748],
../data/rfc/rfc4962.txt- Remote Authentication Dial-In User Service (RADIUS) [RFC2865], and
--
../data/rfc/rfc4962.txt-1.3. Terminology
../data/rfc/rfc4962.txt-
../data/rfc/rfc4962.txt- This section defines terms that are used in this document.
../data/rfc/rfc4962.txt-
../data/rfc/rfc4962.txt- AAA
../data/rfc/rfc4962.txt: Authentication, Authorization, and Accounting (AAA). AAA
../data/rfc/rfc4962.txt- protocols include RADIUS [RFC2865] and Diameter [RFC3588].
../data/rfc/rfc4962.txt-
../data/rfc/rfc4962.txt- Authenticator
../data/rfc/rfc4962.txt- The party initiating EAP authentication. The term
../data/rfc/rfc4962.txt- authenticator is used in [802.1X], and authenticator has the
--
../data/rfc/rfc4962.txt-RFC 4962 Guidance for AAA Key Management July 2007
../data/rfc/rfc4962.txt-
../data/rfc/rfc4962.txt-
../data/rfc/rfc4962.txt-Appendix: AAA Key Management History
../data/rfc/rfc4962.txt-
../data/rfc/rfc4962.txt: Protocols for Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc4962.txt- were originally developed to support deployments of Network Access
../data/rfc/rfc4962.txt- Servers (NASes). In the ARPAnet, the Terminal Access Controller
../data/rfc/rfc4962.txt- (TAC) provided a means for "dumb terminals" to access the network,
../data/rfc/rfc4962.txt- and the TACACS [RFC0927][RFC1492] AAA protocol was designed by BBN
../data/rfc/rfc4962.txt- under contract to the Defense Data Network Program Management Office
--
../data/rfc/rfc4962.txt- impractical for each NAS to contain its own list of users and
../data/rfc/rfc4962.txt- associated credentials. As a result, additional AAA protocols were
../data/rfc/rfc4962.txt- developed, including RADIUS [RFC2865] and Diameter [RFC3588]. These
../data/rfc/rfc4962.txt- protocols enabled a central AAA server to authenticate users
../data/rfc/rfc4962.txt- requesting network access, as well as providing authorization and
../data/rfc/rfc4962.txt: accounting.
../data/rfc/rfc4962.txt-
../data/rfc/rfc4962.txt- While PPP [RFC1661] originally supported only PAP [RFC1334] and CHAP
../data/rfc/rfc4962.txt- [RFC1661] authentication, the limitations of these authentication
../data/rfc/rfc4962.txt- mechanisms became apparent. For example, both PAP and CHAP are
../data/rfc/rfc4962.txt- unilateral authentication schemes supporting only authentication of
--
../data/rfc/rfc4962.txt- However, in practice, such pure two-party schemes are rarely
../data/rfc/rfc4962.txt- deployed. Operation of a centralized AAA server significantly
../data/rfc/rfc4962.txt- reduces the effort required to deploy certificates to NASes, and even
../data/rfc/rfc4962.txt- though an AAA server may not be required for key derivation and
../data/rfc/rfc4962.txt- possibly authentication, its participation is required for service
../data/rfc/rfc4962.txt: authorization and accounting.
../data/rfc/rfc4962.txt-
../data/rfc/rfc4962.txt- "Pass-through" authentication and AAA key distribution has retained
../data/rfc/rfc4962.txt- popularity even in the face of rapid improvements in processor and
../data/rfc/rfc4962.txt- memory capabilities. In addition to producing NAS devices of
../data/rfc/rfc4962.txt- increased capability for enterprise and carrier customers,
--
../data/rfc/rfc4888.txt- However, there are deployment scenarios where allowing unauthorized
../data/rfc/rfc4888.txt- Visiting Mobile Nodes is actually desirable. For instance, when
../data/rfc/rfc4888.txt- Mobile Routers attach to other Mobile Routers and form a nested NEMO,
../data/rfc/rfc4888.txt- they depend on each other to reach the Internet. When Mobile Routers
../data/rfc/rfc4888.txt- have no prior knowledge of one another (no security association,
../data/rfc/rfc4888.txt: Authentication, Authorization, and Accounting (AAA), Public-Key
../data/rfc/rfc4888.txt- Infrastructure (PKI), etc.), it could still be acceptable to forward
../data/rfc/rfc4888.txt- packets, provided that the packets are not tunneled back to the Home
../data/rfc/rfc4888.txt- Networks.
../data/rfc/rfc4888.txt-
../data/rfc/rfc4888.txt- A Route Optimization mechanism that allows traffic from Mobile
--
../data/rfc/rfc7855.txt-
../data/rfc/rfc7855.txt- Capacity planning anticipates the routing of the traffic matrix onto
../data/rfc/rfc7855.txt- the network topology for a set of expected traffic and topology
../data/rfc/rfc7855.txt- variations. The heart of the process consists in simulating the
../data/rfc/rfc7855.txt- placement of the traffic along ECMP-aware shortest paths and
../data/rfc/rfc7855.txt: accounting for the resulting bandwidth usage.
../data/rfc/rfc7855.txt-
../data/rfc/rfc7855.txt: The bandwidth accounting of a demand along its shortest path is a
../data/rfc/rfc7855.txt- basic capability of any planning tool or PCE server.
../data/rfc/rfc7855.txt-
../data/rfc/rfc7855.txt- For example, in the network topology described below, and assuming a
../data/rfc/rfc7855.txt- default IGP metric of 1 and IGP metric of 2 for link GF, a 1600 Mbps
../data/rfc/rfc7855.txt- A-to-Z flow is accounted as consuming 1600 Mbps on links AB and FZ;
--
../data/rfc/rfc136.txt-Network Working Group R. Kahn
../data/rfc/rfc136.txt-Request for Comments: 136 BBN
../data/rfc/rfc136.txt-NIC: 6713 29 April 1971
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt: Host Accounting and Administrative Procedures
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt- A plan must be formulated and agreed upon for the development of a
../data/rfc/rfc136.txt: Host accounting system in the ARPA Network. Such a plan should take
../data/rfc/rfc136.txt: into consideration both current Host accounting practices and new
../data/rfc/rfc136.txt- technical contributions. This document is an early attempt to
../data/rfc/rfc136.txt: identify the issues concerning Host accounting. It is being
../data/rfc/rfc136.txt- distributed as a working document on which further discussions may be
../data/rfc/rfc136.txt- based and, as such, does not represent, nor is intended to represent,
../data/rfc/rfc136.txt- a position on any of these issues.
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt- The method of network operation and the potential for its growth are
../data/rfc/rfc136.txt- relevant factors to be considered in formulating a plan for Host
../data/rfc/rfc136.txt: accounting. For example, the answers to the following questions
../data/rfc/rfc136.txt- provide a useful background for reference:
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt- 1. Who or what operates the Network?
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt- 2. What is the criteria upon which new sites should be
--
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt-Kahn [Page 1]
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt:RFC 136 Host Accounting and Administrative Procedures 29 April 1971
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt-Assumptions Regarding the Network
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt- I have made several assumptions in this presentation that should
../data/rfc/rfc136.txt- simplify and, hopefully, clarify the framework in which the
../data/rfc/rfc136.txt: accounting issues reside. Any one of these assumptions may be
../data/rfc/rfc136.txt- subject to challenge.
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt- 1. Subnet Considerations
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt- 1.1 That some entity, government or private, will undertake to
--
../data/rfc/rfc136.txt- etc. It will further indicate, where appropriate, the status
../data/rfc/rfc136.txt- of equipment (such as government-furnished, leased, or
../data/rfc/rfc136.txt- privately owned) and whether the rates are in accord with
../data/rfc/rfc136.txt- government standards.
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt: 2.3 That the implementation of standard automated accounting
../data/rfc/rfc136.txt- procedures involving the use of the Network will be deferred
../data/rfc/rfc136.txt- until non-automated procedures have been understood and
../data/rfc/rfc136.txt- stabilized. Early experimentation in this area is
../data/rfc/rfc136.txt- appropriate, however.
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt-Kahn [Page 2]
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt:RFC 136 Host Accounting and Administrative Procedures 29 April 1971
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt: 2.4 That no major change in current Host accounting procedures
../data/rfc/rfc136.txt- should be required initially.
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt- 3. Both Host and Subnet Considerations
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt- 3.1 That two kinds of traffic into the Network will be measured by
--
../data/rfc/rfc136.txt- basis or on a link or socket basis. Each Host will be
../data/rfc/rfc136.txt- responsible for distributing the cost of Network usage among
../data/rfc/rfc136.txt- the appropriate users.
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt- 3.3 That some form of duplication, verification, or backup of
../data/rfc/rfc136.txt: accounting information may become desirable.
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt- 3.4 Understanding the relationship between service, improvement,
../data/rfc/rfc136.txt- reliability and cost should be the responsibility of the
../data/rfc/rfc136.txt- Network operator, but that feedback from the Host sites in
../data/rfc/rfc136.txt- this area is absolutely essential.
--
../data/rfc/rfc136.txt- The following set of topics are introduced for discussion among the
../data/rfc/rfc136.txt- network community.
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt- 1. Current Practices
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt: 1.1 What constitutes current Host accounting procedures? How is it
../data/rfc/rfc136.txt- accomplished and what is accounted for?
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt- 2. Administrative Procedures
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt- 2.1 What access arrangements for network users are either planned
../data/rfc/rfc136.txt- or envisioned at each site?
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt- 2.2 Are security or authenticity provisions required for network
../data/rfc/rfc136.txt- usage and if so, what is the nature of that requirement?
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt: 2.3 Should Host accounting and network accounting be completely
../data/rfc/rfc136.txt- independent of each other or not? If not, in what way should
../data/rfc/rfc136.txt- they be made independent?
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt- 2.4 What long range billing procedures are desirable?
../data/rfc/rfc136.txt-
--
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt-Kahn [Page 3]
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt:RFC 136 Host Accounting and Administrative Procedures 29 April 1971
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt- 3. Charging Policies
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt- 3.1 What procedures are required for a Host to determine the most
../data/rfc/rfc136.txt- cost effective way to run a job on the Network? In this
../data/rfc/rfc136.txt- regard, is it helpful to try to categorize resources for
../data/rfc/rfc136.txt- costing purposes?
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt- 3.2 Should some classes of Host activity be exempt from
../data/rfc/rfc136.txt: accounting?
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt- 3.3 Is it desirable to achieve standardized rates for specific
../data/rfc/rfc136.txt- classes of activity, and if so how should those rates be
../data/rfc/rfc136.txt- determined?
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt- 4. Technical Aspects
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt: 4.1 Should Host accounting information eventually flow via the
../data/rfc/rfc136.txt- Network? Should it be accessible to a user or a Host in real-
../data/rfc/rfc136.txt- time? If so, what should flow online?
../data/rfc/rfc136.txt-
../data/rfc/rfc136.txt: 4.2 What accounting mechanisms, if any, are needed to deal with
../data/rfc/rfc136.txt- events, from which recovery or continuation is not possible
../data/rfc/rfc136.txt- that result from use of the Network and lack of proximity to
../data/rfc/rfc136.txt- the computer? To what extent are the procedures in current use
../data/rfc/rfc136.txt- for remote users from the dial-up network applicable?
../data/rfc/rfc136.txt-
--
../data/rfc/rfc3993.txt-RFC 3993 Subscriber-ID Suboption March 2005
../data/rfc/rfc3993.txt-
../data/rfc/rfc3993.txt-
../data/rfc/rfc3993.txt- The Subscriber-ID information allows the service provider to
../data/rfc/rfc3993.txt- assign/activate subscriber-specific actions; e.g., assignment of host
../data/rfc/rfc3993.txt: IP address and subnet mask, DNS configuration, or trigger accounting.
../data/rfc/rfc3993.txt- This suboption is de-coupled from the access network's physical
../data/rfc/rfc3993.txt- structure, so subscriber moves from one access-point to another, for
../data/rfc/rfc3993.txt- example, would not require reconfiguration at the service provider's
../data/rfc/rfc3993.txt- DHCP servers.
../data/rfc/rfc3993.txt-
--
../data/rfc/rfc6908.txt- 2.3. Logging at the AFTR ........................................4
../data/rfc/rfc6908.txt- 2.4. Blacklisting a Shared IPv4 Address .........................5
../data/rfc/rfc6908.txt- 2.5. AFTR's Policies ............................................5
../data/rfc/rfc6908.txt- 2.5.1. Outgoing Policy .....................................5
../data/rfc/rfc6908.txt- 2.5.2. Incoming Policy .....................................6
../data/rfc/rfc6908.txt: 2.6. AFTR Impacts on Accounting Process .........................6
../data/rfc/rfc6908.txt- 2.7. Reliability Considerations of AFTR .........................7
../data/rfc/rfc6908.txt- 2.8. Strategic Placement of AFTR ................................8
../data/rfc/rfc6908.txt- 2.9. AFTR Considerations for Geographically Aware Services ......8
../data/rfc/rfc6908.txt- 2.10. Impacts on QoS Policy .....................................9
../data/rfc/rfc6908.txt- 2.11. Port Forwarding Considerations ............................9
--
../data/rfc/rfc6908.txt- the IPv6 access network to apply certain traffic policies. In this
../data/rfc/rfc6908.txt- deployment scenario, the operator can configure the AFTR to mark the
../data/rfc/rfc6908.txt- incoming packets with the predefined DSCP value. This policy will
../data/rfc/rfc6908.txt- apply to all incoming packets from the IPv4 network.
../data/rfc/rfc6908.txt-
../data/rfc/rfc6908.txt:2.6. AFTR Impacts on Accounting Process
../data/rfc/rfc6908.txt-
../data/rfc/rfc6908.txt: This section discusses IPv4 and IPv6 traffic accounting in the
../data/rfc/rfc6908.txt- DS-Lite environment. In a typical broadband access scenario (e.g.,
../data/rfc/rfc6908.txt- DSL or Cable), the B4 is embedded in a Residential Gateway. The edge
../data/rfc/rfc6908.txt- router for the B4s in the provider's network is an IPv6 edge router.
../data/rfc/rfc6908.txt: The edge router is usually responsible for IPv6 accounting and the
../data/rfc/rfc6908.txt- user management functions such as authentication, authorization, and
../data/rfc/rfc6908.txt: accounting (AAA). However, given the fact that IPv4 traffic is
../data/rfc/rfc6908.txt- encapsulated in an IPv6 packet at the B4 and only decapsulated at the
../data/rfc/rfc6908.txt- AFTR, the edge router will require additional functionality to
../data/rfc/rfc6908.txt: associate IPv4 accounting information to the B4 IPv6 address. If
../data/rfc/rfc6908.txt- DS-Lite is the only application using the IPv4-in-IPv6 protocol in
../data/rfc/rfc6908.txt- the IPv6 access network, the operator can configure the edge router
../data/rfc/rfc6908.txt- to check the IPv6 Next Header field in the IPv6 header, identify the
../data/rfc/rfc6908.txt: protocol type (i.e., 0x04), and collect IPv4 accounting information.
../data/rfc/rfc6908.txt-
../data/rfc/rfc6908.txt: Alternatively, the AFTR may perform accounting for IPv4 traffic.
../data/rfc/rfc6908.txt- However, operators must be aware that this will introduce some
../data/rfc/rfc6908.txt- challenges, especially in DSL deployment. In DSL deployment, the AAA
../data/rfc/rfc6908.txt- transaction normally happens between the edge router (i.e., Broadband
../data/rfc/rfc6908.txt- Network Gateway) and AAA server. [RFC6333] does not require the AFTR
../data/rfc/rfc6908.txt- to interact with the AAA server or edge router. Thus, the AFTR may
../data/rfc/rfc6908.txt- not have the AAA parameters (e.g., Account Session ID) associated
../data/rfc/rfc6908.txt: with B4s to generate an IPv4 accounting record. IPv4 traffic
../data/rfc/rfc6908.txt: accounting at the AFTR is not recommended when the AAA parameters
../data/rfc/rfc6908.txt: necessary to generate complete IPv4 accounting records are not
../data/rfc/rfc6908.txt: available. The accounting process at the AFTR is only necessary if
../data/rfc/rfc6908.txt: the operator requires separating per-B4 accounting records for IPv4
../data/rfc/rfc6908.txt: and IPv6 traffic. If the per-B4 IPv6 accounting records, collected
../data/rfc/rfc6908.txt-
../data/rfc/rfc6908.txt-
../data/rfc/rfc6908.txt-
../data/rfc/rfc6908.txt-Lee, et al. Informational [Page 6]
../data/rfc/rfc6908.txt-
../data/rfc/rfc6908.txt-RFC 6908 Deployment Considerations for DS-Lite March 2013
../data/rfc/rfc6908.txt-
../data/rfc/rfc6908.txt-
../data/rfc/rfc6908.txt- by the edge router, are sufficient, then the additional complexity of
../data/rfc/rfc6908.txt: enabling IPv4 accounting at the AFTR is not required. It is
../data/rfc/rfc6908.txt- important to notice that, since the IPv4 traffic is encapsulated in
../data/rfc/rfc6908.txt- IPv6 packets, the data collected by the edge router for IPv6 traffic
../data/rfc/rfc6908.txt- already contains the total amount of traffic (i.e., IPv4 and IPv6).
../data/rfc/rfc6908.txt-
../data/rfc/rfc6908.txt: Even if detailed accounting records collection for IPv4 traffic may
../data/rfc/rfc6908.txt- not be required, it would be useful for an operator, in some
../data/rfc/rfc6908.txt- scenarios, to have information that the edge router generates for the
../data/rfc/rfc6908.txt- IPv6 traffic. This information can be used to identify the AFTR who
../data/rfc/rfc6908.txt- is handling the IPv4 traffic for that B4. This can be achieved by
../data/rfc/rfc6908.txt: adding additional information to the IPv6 accounting records. For
../data/rfc/rfc6908.txt- example, operators can use RADIUS attribute information specified in
../data/rfc/rfc6908.txt- [RFC6519] or a new attribute to be specified in Internet Protocol
../data/rfc/rfc6908.txt- Detailed Record (IPDR).
../data/rfc/rfc6908.txt-
../data/rfc/rfc6908.txt-2.7. Reliability Considerations of AFTR
--
../data/rfc/rfc3758.txt- The following are some of the advantages for integrating partially
../data/rfc/rfc3758.txt- reliable data service into SCTP, i.e., benefits of PR-SCTP:
../data/rfc/rfc3758.txt-
../data/rfc/rfc3758.txt- 1. Some application layer protocols may benefit from being able to
../data/rfc/rfc3758.txt- use a single SCTP association to carry both reliable content, --
../data/rfc/rfc3758.txt: such as text pages, billing and accounting information, setup
../data/rfc/rfc3758.txt- signaling -- and unreliable content, e.g., state that is highly
../data/rfc/rfc3758.txt- sensitive to timeliness, where generating a new packet is more
../data/rfc/rfc3758.txt- advantageous than transmitting an old one [3].
../data/rfc/rfc3758.txt-
../data/rfc/rfc3758.txt- 2. Partially reliable data traffic carried by PR-SCTP will enjoy the
--
../data/rfc/rfc5447.txt- utilizing Mobile IPv6. RFC 3775 requires that some or all of these
../data/rfc/rfc5447.txt- parameters be statically configured. Mobile IPv6 bootstrapping work
../data/rfc/rfc5447.txt- aims to make this information dynamically available to the mobile
../data/rfc/rfc5447.txt- node. An important aspect of the Mobile IPv6 bootstrapping solution
../data/rfc/rfc5447.txt- is to support interworking with existing Authentication,
../data/rfc/rfc5447.txt: Authorization, and Accounting (AAA) infrastructures. This document
../data/rfc/rfc5447.txt- describes MIPv6 bootstrapping using the Diameter Network Access
../data/rfc/rfc5447.txt- Server to home AAA server interface.
../data/rfc/rfc5447.txt-
../data/rfc/rfc5447.txt-
../data/rfc/rfc5447.txt-
--
../data/rfc/rfc5447.txt-
../data/rfc/rfc5447.txt- A device that provides an access service for a user to a network.
../data/rfc/rfc5447.txt-
../data/rfc/rfc5447.txt- Home AAA (HAAA):
../data/rfc/rfc5447.txt-
../data/rfc/rfc5447.txt: An Authentication, Authorization, and Accounting server located in
../data/rfc/rfc5447.txt- the user's home network, i.e., in the home realm.
../data/rfc/rfc5447.txt-
../data/rfc/rfc5447.txt- Local AAA (LAAA):
../data/rfc/rfc5447.txt-
../data/rfc/rfc5447.txt: An Authentication, Authorization, and Accounting proxy located in
../data/rfc/rfc5447.txt- the local (ASP) network.
../data/rfc/rfc5447.txt-
../data/rfc/rfc5447.txt- Visited AAA (VAAA):
../data/rfc/rfc5447.txt-
../data/rfc/rfc5447.txt: An Authentication, Authorization, and Accounting proxy located in
../data/rfc/rfc5447.txt- a visited network, i.e., in the visited realm. In a roaming case,
../data/rfc/rfc5447.txt- the local Diameter proxy has the VAAA role (see Figure 1).
../data/rfc/rfc5447.txt-
../data/rfc/rfc5447.txt-
../data/rfc/rfc5447.txt-
--
../data/rfc/rfc5447.txt-
../data/rfc/rfc5447.txt-
../data/rfc/rfc5447.txt-3. Overview
../data/rfc/rfc5447.txt-
../data/rfc/rfc5447.txt- This document addresses the Authentication, Authorization, and
../data/rfc/rfc5447.txt: Accounting (AAA) functionality required for the MIPv6 bootstrapping
../data/rfc/rfc5447.txt- solutions outlined in [RFC4640], and focuses on the Diameter-based
../data/rfc/rfc5447.txt- AAA functionality for the NAS-to-HAAA (home AAA) server
../data/rfc/rfc5447.txt- communication.
../data/rfc/rfc5447.txt-
../data/rfc/rfc5447.txt- In the integrated scenario, MIPv6 bootstrapping is provided as part
--
../data/rfc/rfc3580.txt-Table of Contents
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
../data/rfc/rfc3580.txt- 1.1. Terminology. . . . . . . . . . . . . . . . . . . . . . . 3
../data/rfc/rfc3580.txt- 1.2. Requirements Language. . . . . . . . . . . . . . . . . . 4
../data/rfc/rfc3580.txt: 2. RADIUS Accounting Attributes . . . . . . . . . . . . . . . . . 5
../data/rfc/rfc3580.txt- 2.1. Acct-Terminate-Cause . . . . . . . . . . . . . . . . . . 5
../data/rfc/rfc3580.txt- 2.2. Acct-Multi-Session-Id. . . . . . . . . . . . . . . . . . 6
../data/rfc/rfc3580.txt- 2.3. Acct-Link-Count. . . . . . . . . . . . . . . . . . . . . 7
../data/rfc/rfc3580.txt- 3. RADIUS Authentication. . . . . . . . . . . . . . . . . . . . . 7
../data/rfc/rfc3580.txt- 3.1. User-Name. . . . . . . . . . . . . . . . . . . . . . . . 8
--
../data/rfc/rfc3580.txt- IEEE 802.1X does not require use of a backend Authentication Server,
../data/rfc/rfc3580.txt- and thus can be deployed with stand-alone bridges or Access Points,
../data/rfc/rfc3580.txt- as well as in centrally managed scenarios.
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt- In situations where it is desirable to centrally manage
../data/rfc/rfc3580.txt: authentication, authorization and accounting (AAA) for IEEE 802
../data/rfc/rfc3580.txt: networks, deployment of a backend authentication and accounting
../data/rfc/rfc3580.txt- server is desirable. In such situations, it is expected that IEEE
../data/rfc/rfc3580.txt- 802.1X Authenticators will function as AAA clients.
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt- This document provides suggestions on RADIUS usage by IEEE 802.1X
../data/rfc/rfc3580.txt- Authenticators. Support for any AAA protocol is optional for IEEE
--
../data/rfc/rfc3580.txt-Congdon, et al. Informational [Page 4]
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt-RFC 3580 IEEE 802.1X RADIUS September 2003
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt:2. RADIUS Accounting Attributes
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt: With a few exceptions, the RADIUS accounting attributes defined in
../data/rfc/rfc3580.txt- [RFC2866], [RFC2867], and [RFC2869] have the same meaning within IEEE
../data/rfc/rfc3580.txt- 802.1X sessions as they do in dialup sessions and therefore no
../data/rfc/rfc3580.txt- additional commentary is needed.
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt- Attributes requiring more discussion include:
--
../data/rfc/rfc3580.txt- explicit re-authentication request by management action.
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt- Within [IEEE80211], periodic re-authentication may be useful in
../data/rfc/rfc3580.txt- preventing reuse of an initialization vector with a given key. Since
../data/rfc/rfc3580.txt- successful re-authentication does not result in termination of the
../data/rfc/rfc3580.txt: session, accounting packets are not sent as a result of
../data/rfc/rfc3580.txt- re-authentication unless the status of the session changes. For
../data/rfc/rfc3580.txt- example:
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt- a. The session is terminated due to re-authentication failure. In
../data/rfc/rfc3580.txt- this case the Reauthentication Failure (20) termination cause is
../data/rfc/rfc3580.txt- used.
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt- b. The authorizations are changed as a result of a successful
../data/rfc/rfc3580.txt- re-authentication. In this case, the Service Unavailable (15)
../data/rfc/rfc3580.txt: termination cause is used. For accounting purposes, the portion
../data/rfc/rfc3580.txt- of the session after the authorization change is treated as a
../data/rfc/rfc3580.txt- separate session.
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt- Where IEEE 802.1X authentication occurs prior to association,
../data/rfc/rfc3580.txt: accounting packets are not sent until an association occurs.
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt- An Admin Reset (6) termination cause indicates that the Port has been
../data/rfc/rfc3580.txt- administratively forced into the unauthorized state.
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt- A Port Reinitialized (21) termination cause indicates that the Port's
--
../data/rfc/rfc3580.txt-2.2. Acct-Multi-Session-Id
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt- The purpose of this attribute is to make it possible to link together
../data/rfc/rfc3580.txt- multiple related sessions. While [IEEE8021X] does not act on
../data/rfc/rfc3580.txt- aggregated ports, it is possible for a Supplicant roaming between
../data/rfc/rfc3580.txt: Access Points to cause multiple RADIUS accounting packets to be sent
../data/rfc/rfc3580.txt- by different Access Points.
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt- Where supported by the Access Points, the Acct-Multi-Session-Id
../data/rfc/rfc3580.txt- attribute can be used to link together the multiple related sessions
../data/rfc/rfc3580.txt- of a roaming Supplicant. In such a situation, if the session context
../data/rfc/rfc3580.txt: is transferred between Access Points, accounting packets MAY be sent
../data/rfc/rfc3580.txt- without a corresponding authentication and authorization exchange,
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt-
--
../data/rfc/rfc3580.txt- the Access Points as part of the Inter-Access Point Protocol (IAPP).
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt- If the Acct-Multi-Session-Id were not unique between Access Points,
../data/rfc/rfc3580.txt- then it is possible that the chosen Acct-Multi-Session-Id will
../data/rfc/rfc3580.txt- overlap with an existing value allocated on that Access Point, and
../data/rfc/rfc3580.txt: the Accounting Server would therefore be unable to distinguish a
../data/rfc/rfc3580.txt- roaming session from a multi-link session.
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt- As a result, the Acct-Multi-Session-Id attribute is unique among all
../data/rfc/rfc3580.txt- the bridges or Access Points, Supplicants and sessions. In order to
../data/rfc/rfc3580.txt- provide this uniqueness, it is suggested that the Acct-Multi-
--
../data/rfc/rfc3580.txt- This attribute is sent by a bridge or Access Point to indicate the
../data/rfc/rfc3580.txt- nature of the Supplicant's connection. When sent in the Access-
../data/rfc/rfc3580.txt- Request it is recommended that this attribute contain information on
../data/rfc/rfc3580.txt- the speed of the Supplicant's connection. For 802.11, the following
../data/rfc/rfc3580.txt- format is recommended: "CONNECT 11Mbps 802.11b". If sent in the
../data/rfc/rfc3580.txt: Accounting STOP, this attribute may be used to summarize statistics
../data/rfc/rfc3580.txt- relating to session quality. For example, in IEEE 802.11, the
../data/rfc/rfc3580.txt- Connect-Info attribute may contain information on the number of link
../data/rfc/rfc3580.txt- layer retransmissions. The exact format of this attribute is
../data/rfc/rfc3580.txt- implementation specific.
../data/rfc/rfc3580.txt-
--
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt-3.31. Tunnel Attributes
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt- Reference [RFC2868] defines RADIUS tunnel attributes used for
../data/rfc/rfc3580.txt- authentication and authorization, and [RFC2867] defines tunnel
../data/rfc/rfc3580.txt: attributes used for accounting. Where the IEEE 802.1X Authenticator
../data/rfc/rfc3580.txt- supports tunneling, a compulsory tunnel may be set up for the
../data/rfc/rfc3580.txt- Supplicant as a result of the authentication.
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt- In particular, it may be desirable to allow a port to be placed into
../data/rfc/rfc3580.txt- a particular Virtual LAN (VLAN), defined in [IEEE8021Q], based on the
--
../data/rfc/rfc3580.txt- 48 octet RC4 key (384 bits).
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt-5. Security Considerations
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt- Since this document describes the use of RADIUS for purposes of
../data/rfc/rfc3580.txt: authentication, authorization, and accounting in IEEE 802.1X-enabled
../data/rfc/rfc3580.txt- networks, it is vulnerable to all of the threats that are present in
../data/rfc/rfc3580.txt- other RADIUS applications. For a discussion of these threats, see
../data/rfc/rfc3580.txt- [RFC2607], [RFC2865], [RFC3162], [RFC3579], and [RFC3576].
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt- Vulnerabilities include:
--
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt-5.4. Replay
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt- As noted in [RFC3579] Section 4.3.5., the RADIUS protocol provides
../data/rfc/rfc3580.txt- only limited support for replay protection. Replay protection for
../data/rfc/rfc3580.txt: RADIUS authentication and accounting can be provided by enabling
../data/rfc/rfc3580.txt- IPsec replay protection with RADIUS, as described in [RFC3579],
../data/rfc/rfc3580.txt- Section 4.2.
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt- As with the Request Authenticator, for use with IEEE 802.1X
../data/rfc/rfc3580.txt- Authenticators, the Acct-Session-Id SHOULD be globally and temporally
--
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt- [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
../data/rfc/rfc3580.txt- "Remote Authentication Dial In User Service (RADIUS)",
../data/rfc/rfc3580.txt- RFC 2865, June 2000.
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt: [RFC2867] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
../data/rfc/rfc3580.txt- Modifications for Tunnel Protocol Support", RFC 2867,
../data/rfc/rfc3580.txt- June 2000.
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt-
../data/rfc/rfc3580.txt-
--
../data/rfc/rfc2123.txt-
../data/rfc/rfc2123.txt-1 Introduction
../data/rfc/rfc2123.txt-
../data/rfc/rfc2123.txt- Early in 1992 my University needed to develop a system for recovering
../data/rfc/rfc2123.txt- the costs of its Internet traffic. In March of that year I attended
../data/rfc/rfc2123.txt: the Internet Accounting Working Group's session at the San Diego
../data/rfc/rfc2123.txt- IETF, where I was delighted to find that the Group had produced a
../data/rfc/rfc2123.txt- detailed architecture for measuring network traffic and were waiting
../data/rfc/rfc2123.txt- for someone to try implementing it.
../data/rfc/rfc2123.txt-
../data/rfc/rfc2123.txt- During 1992 I produced a prototype measurement system, using balanced
--
../data/rfc/rfc1844.txt- 2. System installation, configuration and management
../data/rfc/rfc1844.txt- 2.1 How complex/easy is installation and configuration? Are
../data/rfc/rfc1844.txt- there any pitfalls that need attention? Can you configure
../data/rfc/rfc1844.txt- per set of users (i.e systemwide or LAN wide default
../data/rfc/rfc1844.txt- configuration) and/or per user?
../data/rfc/rfc1844.txt: 2.2 Are there facilities for logging and/or accounting?
../data/rfc/rfc1844.txt- 2.3 Does the UA generate correct RFC-822 headers for outgoing
../data/rfc/rfc1844.txt- messages:
../data/rfc/rfc1844.txt- From:, (and if necessary) Sender:
../data/rfc/rfc1844.txt- Date:
../data/rfc/rfc1844.txt- Message-id:
--
../data/rfc/rfc1060.txt- 64-149 Unassigned [JBP]
../data/rfc/rfc1060.txt- 150 Xerox NS IDP [133,XEROX]
../data/rfc/rfc1060.txt- 151 Unassigned [JBP]
../data/rfc/rfc1060.txt- 152 PARC Universal Protocol [8,XEROX]
../data/rfc/rfc1060.txt- 153 TIP Status Reporting [JGH]
../data/rfc/rfc1060.txt: 154 TIP Accounting [JGH]
../data/rfc/rfc1060.txt- 155 Internet Protocol [regular] [105,JBP]
../data/rfc/rfc1060.txt- 156-158 Internet Protocol [experimental] [105,JBP]
../data/rfc/rfc1060.txt- 159 Figleaf Link [JBW1]
../data/rfc/rfc1060.txt- 160 Blacker Local Network Protocol [DM28]
../data/rfc/rfc1060.txt- 161-194 Unassigned [JBP]
--
../data/rfc/rfc7832.txt- Where this service is currently offered, it would usually be achieved
../data/rfc/rfc7832.txt- through the use of "open" printers (i.e., printers that allow
../data/rfc/rfc7832.txt- anonymous print requests), where printer availability is advertised
../data/rfc/rfc7832.txt- through the use of Bonjour or other similar protocols. If the
../data/rfc/rfc7832.txt- organization requires authenticated print requests (usually for
../data/rfc/rfc7832.txt: accounting purposes), the visitor would usually have to be given
../data/rfc/rfc7832.txt- credentials that allow this, often supplemented with pay-as-you-go
../data/rfc/rfc7832.txt- style payment systems.
../data/rfc/rfc7832.txt-
../data/rfc/rfc7832.txt- Adding federated authentication to the Internet Printing Protocol
../data/rfc/rfc7832.txt- (IPP) [RFC2911] (and other relevant protocols) would enable this kind
--
../data/rfc/rfc1862.txt- is or should be any access time enforcement or only after the fact
../data/rfc/rfc1862.txt- enforcement. The information is likely to be in the form of
../data/rfc/rfc1862.txt- attribute-value pairs and must be able to capture copyright knowledge
../data/rfc/rfc1862.txt- effectively.
../data/rfc/rfc1862.txt-
../data/rfc/rfc1862.txt: * ACCOUNTING: An accounting service provides metering of the use of
../data/rfc/rfc1862.txt- resources. The resources wholly contained in the wholesale layer are
../data/rfc/rfc1862.txt- the services discussed here. It will also be important to provide
../data/rfc/rfc1862.txt- metering tools in the wholesale layer to be used by the retail layer
../data/rfc/rfc1862.txt- to meter usage or content access in that layer. Metering may be used
../data/rfc/rfc1862.txt- for a variety of purposes ranging from providing better utilization
../data/rfc/rfc1862.txt- or service from the resources to pricing and billing. Hence
../data/rfc/rfc1862.txt: accounting services will be used by object storage, caching and
../data/rfc/rfc1862.txt- replication, lower layer networking services, as well as pricing and
../data/rfc/rfc1862.txt- billing services. In the form of content metering it will also
../data/rfc/rfc1862.txt- interact with attribute management.
../data/rfc/rfc1862.txt-
../data/rfc/rfc1862.txt-
--
../data/rfc/rfc1862.txt- that caching and replication are important, but the discussion of
../data/rfc/rfc1862.txt- that was left to another group that had taken that as the focus of
../data/rfc/rfc1862.txt- their agenda. Object storage will take an object and put it
../data/rfc/rfc1862.txt- somewhere, while maintaining both the identity and nature of the
../data/rfc/rfc1862.txt- object. It is tightly coupled to caching and replication, as well as
../data/rfc/rfc1862.txt: accounting, often in order to determine patterns of caching and
../data/rfc/rfc1862.txt- replication. It is also tightly coupled to object publication,
../data/rfc/rfc1862.txt- translation, and provides interfaces to both supporting storage
../data/rfc/rfc1862.txt- facilities such as local file systems, as well as direct access from
../data/rfc/rfc1862.txt- applications, needing access to objects.
../data/rfc/rfc1862.txt-
--
../data/rfc/rfc1862.txt- for the ability to create or import objects into this object world by
../data/rfc/rfc1862.txt- the publication paradigm, and allows objects to evolve to support new
../data/rfc/rfc1862.txt- or evolving functionality through the translation paradigm. Access
../data/rfc/rfc1862.txt- to the objects is provided by object storage, enhanced with caching
../data/rfc/rfc1862.txt- and replication services and mediated by the attributes managed by
../data/rfc/rfc1862.txt: attribute management and accounting or content metering. Discovery
../data/rfc/rfc1862.txt- of resources (figuring out which identifier to be chasing) is
../data/rfc/rfc1862.txt- provided by resource discovery services. Types are registered and
../data/rfc/rfc1862.txt- hence available both as definitions and perhaps in the form of
../data/rfc/rfc1862.txt- implementations from a definition service. Lastly, there is a
../data/rfc/rfc1862.txt- vertical model of providing the two-way services of adaptive glue for
--
../data/rfc/rfc7683.txt-
../data/rfc/rfc7683.txt-9.1. AVP Codes
../data/rfc/rfc7683.txt-
../data/rfc/rfc7683.txt- New AVPs defined by this specification are listed in Section 7. All
../data/rfc/rfc7683.txt- AVP codes are allocated from the "AVP Codes" sub-registry under the
../data/rfc/rfc7683.txt: "Authentication, Authorization, and Accounting (AAA) Parameters"
../data/rfc/rfc7683.txt- registry.
../data/rfc/rfc7683.txt-
../data/rfc/rfc7683.txt-9.2. New Registries
../data/rfc/rfc7683.txt-
../data/rfc/rfc7683.txt- Two new registries have been created in the "AVP Specific Values"
../data/rfc/rfc7683.txt: sub-registry under the "Authentication, Authorization, and Accounting
../data/rfc/rfc7683.txt- (AAA) Parameters" registry.
../data/rfc/rfc7683.txt-
../data/rfc/rfc7683.txt- A new "OC-Feature-Vector AVP Values (code 622)" registry has been
../data/rfc/rfc7683.txt- created. This registry contains the following:
../data/rfc/rfc7683.txt-
--
../data/rfc/rfc1726.txt- 6. Things We Chose Not to Require. . . . . . . . . . . . . . 26
../data/rfc/rfc1726.txt- 6.1 Fragmentation . . . . . . . . . . . . . . . . . . . . . . 26
../data/rfc/rfc1726.txt- 6.2 IP Header Checksum. . . . . . . . . . . . . . . . . . . . 26
../data/rfc/rfc1726.txt- 6.3 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 27
../data/rfc/rfc1726.txt- 6.4 Network Management. . . . . . . . . . . . . . . . . . . . 27
../data/rfc/rfc1726.txt: 6.5 Accounting. . . . . . . . . . . . . . . . . . . . . . . . 27
../data/rfc/rfc1726.txt- 6.6 Routing . . . . . . . . . . . . . . . . . . . . . . . . . 27
../data/rfc/rfc1726.txt- 6.6.1 Scale . . . . . . . . . . . . . . . . . . . . . . . . . . 28
../data/rfc/rfc1726.txt- 6.6.2 Policy. . . . . . . . . . . . . . . . . . . . . . . . . . 28
../data/rfc/rfc1726.txt- 6.6.3 QOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
../data/rfc/rfc1726.txt- 6.6.4 Feedback. . . . . . . . . . . . . . . . . . . . . . . . . 28
--
../data/rfc/rfc1726.txt-Partridge and Kastenholz [Page 14]
../data/rfc/rfc1726.txt-
../data/rfc/rfc1726.txt-RFC 1726 IPng Technical Criteria December 1994
../data/rfc/rfc1726.txt-
../data/rfc/rfc1726.txt-
../data/rfc/rfc1726.txt: integral accounting and billing capabilities, and IPng must
../data/rfc/rfc1726.txt- provide the correct control information to such subnetworks.
../data/rfc/rfc1726.txt-
../data/rfc/rfc1726.txt- Time Frame
../data/rfc/rfc1726.txt- Specifications for current media encapsulations (i.e., all
../data/rfc/rfc1726.txt- encapsulations that are currently Proposed standards, or higher,
--
../data/rfc/rfc1726.txt- routing system within the network. This criterion covers those
../data/rfc/rfc1726.txt- aspects of security that are not needed to provide the Robustness
../data/rfc/rfc1726.txt- criterion.
../data/rfc/rfc1726.txt-
../data/rfc/rfc1726.txt- Another aspect of security is non-repudiation of origin. In order
../data/rfc/rfc1726.txt: to adequately support the expected need for simple accounting, we
../data/rfc/rfc1726.txt- believe that this is a necessary feature.
../data/rfc/rfc1726.txt-
../data/rfc/rfc1726.txt- In order to safely support requirements of the commercial world,
../data/rfc/rfc1726.txt- IPng-level security must have capabilities to prevent
../data/rfc/rfc1726.txt- eavesdroppers from monitoring traffic and deducing traffic
--
../data/rfc/rfc1726.txt- globally unique, unambiguous, and ubiquitous names for endpoints,
../data/rfc/rfc1726.txt- nodes, interfaces, and the like. Every datagram must carry the
../data/rfc/rfc1726.txt- identifier of both its source and its destination (or some method
../data/rfc/rfc1726.txt- must be available to determine these identifiers, given a
../data/rfc/rfc1726.txt- datagram). We believe that this is required in order to support
../data/rfc/rfc1726.txt: certain accounting functions.
../data/rfc/rfc1726.txt-
../data/rfc/rfc1726.txt- Other functions and uses of unique names are:
../data/rfc/rfc1726.txt-
../data/rfc/rfc1726.txt- * To uniquely identify endpoints (thus if the unique name and
../data/rfc/rfc1726.txt- address are not the same, the TCP pseudo-header should include
--
../data/rfc/rfc1726.txt-
../data/rfc/rfc1726.txt-RFC 1726 IPng Technical Criteria December 1994
../data/rfc/rfc1726.txt-
../data/rfc/rfc1726.txt-
../data/rfc/rfc1726.txt- DISCUSSION
../data/rfc/rfc1726.txt: For many reasons, such as accounting, security and multimedia, it
../data/rfc/rfc1726.txt- is desirable to treat different packets differently in the
../data/rfc/rfc1726.txt- network.
../data/rfc/rfc1726.txt-
../data/rfc/rfc1726.txt- For example, multimedia is now on our desktop and will be an
../data/rfc/rfc1726.txt- essential part of future networking. So we have to find ways to
--
../data/rfc/rfc1726.txt- network management, per se, is not an attribute of the IPng protocol.
../data/rfc/rfc1726.txt- Furthermore, network management is viewed as a support, or service,
../data/rfc/rfc1726.txt- function. Network management should be developed to fit IPng and not
../data/rfc/rfc1726.txt- the other way round.
../data/rfc/rfc1726.txt-
../data/rfc/rfc1726.txt:6.5 Accounting
../data/rfc/rfc1726.txt-
../data/rfc/rfc1726.txt: We believe that accounting, like network management, must be designed
../data/rfc/rfc1726.txt- to fit the IPng protocol, and not the other way round. Therefore,
../data/rfc/rfc1726.txt: accounting, in and of itself, is not a requirement of IPng. However,
../data/rfc/rfc1726.txt- there are some facets of the protocol that have been specified to
../data/rfc/rfc1726.txt: make accounting easier, such as non-repudiation of origin under
../data/rfc/rfc1726.txt- security, and the unique naming requirement for sorting datagrams
../data/rfc/rfc1726.txt- into classes. Note that a parameter of network service that IPng
../data/rfc/rfc1726.txt- must support is cost.
../data/rfc/rfc1726.txt-
../data/rfc/rfc1726.txt-6.6 Routing
--
../data/rfc/rfc1510.txt- Project Athena, Cambridge, Mas sachusetts (1987).
../data/rfc/rfc1510.txt-
../data/rfc/rfc1510.txt- [8] CCITT, Recommendation X.509: The Directory Authentication
../data/rfc/rfc1510.txt- Framework, December 1988.
../data/rfc/rfc1510.txt-
../data/rfc/rfc1510.txt: [9] Neuman, C., "Proxy-Based Authorization and Accounting for
../data/rfc/rfc1510.txt- Distributed Systems," in Proceedings of the 13th International
../data/rfc/rfc1510.txt- Conference on Distributed Computing Systems", Pittsburgh, PA,
../data/rfc/rfc1510.txt- May 1993.
../data/rfc/rfc1510.txt-
../data/rfc/rfc1510.txt- [10] Pato, J., "Using Pre-Authentication to Avoid Password Guessing
--
../data/rfc/rfc2208.txt-
../data/rfc/rfc2208.txt- Before any decision to deploy RSVP, it would be wise to ensure that
../data/rfc/rfc2208.txt- the policy control available from a vendor is adequate for the
../data/rfc/rfc2208.txt- intended usage. In addition to the lack of documented policy
../data/rfc/rfc2208.txt- mechanisms in any of the policy areas (such as access control,
../data/rfc/rfc2208.txt: authorization, and accounting), the community has little experience
../data/rfc/rfc2208.txt- with describing, setting and controlling policies that limit Internet
../data/rfc/rfc2208.txt- service. Therefore it is likely that vendor solutions will be
../data/rfc/rfc2208.txt- revised often, particularly before the IETF has developed any policy
../data/rfc/rfc2208.txt- specification.
../data/rfc/rfc2208.txt-
--
../data/rfc/rfc1753.txt- which provide those services.
../data/rfc/rfc1753.txt-
../data/rfc/rfc1753.txt- To the internetworking layer, a flow is a sequence of packets that
../data/rfc/rfc1753.txt- share all the attributes that the internetworking layer cares about.
../data/rfc/rfc1753.txt- This includes, but is not limited to: source/destination, path,
../data/rfc/rfc1753.txt: resource allocation, accounting/authorization,
../data/rfc/rfc1753.txt- authentication/security, etc., etc.
../data/rfc/rfc1753.txt-
../data/rfc/rfc1753.txt- There isn't necessarily a one-one mapping from flows to *anything*
../data/rfc/rfc1753.txt- else, be it a TCP connection, or an application instance, or
../data/rfc/rfc1753.txt- whatever. A single flow might contain several TCP connections (e.g.,
--
../data/rfc/rfc1753.txt- more complex than unicast (there is a large pool of state which must
../data/rfc/rfc1753.txt- be made coherent), but the concepts are similar.
../data/rfc/rfc1753.txt-
../data/rfc/rfc1753.txt- There's an interesting architectural issue here. Let's assume we have
../data/rfc/rfc1753.txt- all these different internetwork level subsystems (routing, resource
../data/rfc/rfc1753.txt: allocation, security/access-control, accounting), etc. Now, we have
../data/rfc/rfc1753.txt- two choices.
../data/rfc/rfc1753.txt-
../data/rfc/rfc1753.txt- First, we could allow each individual subsystem which uses the
../data/rfc/rfc1753.txt- concept of flows to define itself what it thinks a "flow" is, and
../data/rfc/rfc1753.txt- define which values in which fields in the packet define a given
--
../data/rfc/rfc2072.txt- executable code for generating ranges of test addresses. Such
../data/rfc/rfc2072.txt- scripts may, at first examination, not appear to contain explicit IP
../data/rfc/rfc2072.txt- addresses. They may, for example, contain a "seed" address used with
../data/rfc/rfc2072.txt- an incrementing loop.
../data/rfc/rfc2072.txt-
../data/rfc/rfc2072.txt:12.5 Accounting Management
../data/rfc/rfc2072.txt-
../data/rfc/rfc2072.txt: Accounting records may be sent periodically to syslogd or as SNMP
../data/rfc/rfc2072.txt- traps. Alternatively, the SNMP manager or other management
../data/rfc/rfc2072.txt: applications may periodically poll accounting information in routers,
../data/rfc/rfc2072.txt- and thus contain hard-coded IP addresses.
../data/rfc/rfc2072.txt-
../data/rfc/rfc2072.txt-12.6 Security Management
../data/rfc/rfc2072.txt-
../data/rfc/rfc2072.txt- Security management includes logging, authentication, filtering, and
--
../data/rfc/rfc5807.txt- PEMK and its associated states MUST be deleted.
../data/rfc/rfc5807.txt-
../data/rfc/rfc5807.txt-4. Security Considerations
../data/rfc/rfc5807.txt-
../data/rfc/rfc5807.txt- The following considerations are specifically made to follow the
../data/rfc/rfc5807.txt: Authentication, Authorization, and Accounting (AAA) key management
../data/rfc/rfc5807.txt- guidance [RFC4962]. Other AAA key management requirements such as
../data/rfc/rfc5807.txt- key lifetime, key scope, key context, and key name are described in
../data/rfc/rfc5807.txt- Section 3.
../data/rfc/rfc5807.txt-
../data/rfc/rfc5807.txt-4.1. Channel Binding
--
../data/rfc/rfc5807.txt-
../data/rfc/rfc5807.txt- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
../data/rfc/rfc5807.txt- Requirement Levels", BCP 14, RFC 2119, March 1997.
../data/rfc/rfc5807.txt-
../data/rfc/rfc5807.txt- [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
../data/rfc/rfc5807.txt: Authorization, and Accounting (AAA) Key Management",
../data/rfc/rfc5807.txt- BCP 132, RFC 4962, July 2007.
../data/rfc/rfc5807.txt-
../data/rfc/rfc5807.txt- [RFC5193] Jayaraman, P., Lopez, R., Ohba, Y., Parthasarathy, M.,
../data/rfc/rfc5807.txt- and A. Yegin, "Protocol for Carrying Authentication for
../data/rfc/rfc5807.txt- Network Access (PANA) Framework", RFC 5193, May 2008.
--
../data/rfc/rfc8030.txt- response with the actual TTL. This TTL value MUST be less than or
../data/rfc/rfc8030.txt- equal to the value provided by the application server.
../data/rfc/rfc8030.txt-
../data/rfc/rfc8030.txt- Once the TTL period elapses, the push service MUST NOT attempt to
../data/rfc/rfc8030.txt- deliver the push message to the user agent. A push service might
../data/rfc/rfc8030.txt: adjust the TTL value to account for time accounting errors in
../data/rfc/rfc8030.txt- processing. For instance, distributing a push message within a
../data/rfc/rfc8030.txt- server cluster might accrue errors due to clock skew or propagation
../data/rfc/rfc8030.txt- delays.
../data/rfc/rfc8030.txt-
../data/rfc/rfc8030.txt- A push service is not obligated to account for time spent by the
--
../data/rfc/rfc8371.txt-1. Introduction
../data/rfc/rfc8371.txt-
../data/rfc/rfc8371.txt- The "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)" [RFC4283]
../data/rfc/rfc8371.txt- has proved to be a popular design tool for providing identifiers for
../data/rfc/rfc8371.txt- mobile nodes during authentication procedures with Authentication,
../data/rfc/rfc8371.txt: Authorization, and Accounting (AAA) protocols such as Diameter
../data/rfc/rfc8371.txt- [RFC6733]. To date, only a single type of identifier has been
../data/rfc/rfc8371.txt- specified, namely the Mobile Node (MN) NAI. Other types of
../data/rfc/rfc8371.txt- identifiers are in common use and are even referenced in RFC 4283.
../data/rfc/rfc8371.txt- In this document, we propose adding some basic identifier types that
../data/rfc/rfc8371.txt- are defined in various telecommunications standards, including types
--
../data/rfc/rfc2849.txt-sn: Jensen
../data/rfc/rfc2849.txt-uid: bjensen
../data/rfc/rfc2849.txt-telephonenumber: +1 408 555 1212
../data/rfc/rfc2849.txt-description: A big sailing fan.
../data/rfc/rfc2849.txt-
../data/rfc/rfc2849.txt:dn: cn=Bjorn Jensen, ou=Accounting, dc=airius, dc=com
../data/rfc/rfc2849.txt-objectclass: top
../data/rfc/rfc2849.txt-objectclass: person
../data/rfc/rfc2849.txt-objectclass: organizationalPerson
../data/rfc/rfc2849.txt-cn: Bjorn Jensen
../data/rfc/rfc2849.txt-sn: Jensen
--
../data/rfc/rfc2849.txt-# the directory tree (only implemented by LDAPv3 servers).
../data/rfc/rfc2849.txt-dn: ou=PD Accountants, ou=Product Development, dc=airius, dc=com
../data/rfc/rfc2849.txt-changetype: modrdn
../data/rfc/rfc2849.txt-newrdn: ou=Product Development Accountants
../data/rfc/rfc2849.txt-deleteoldrdn: 0
../data/rfc/rfc2849.txt:newsuperior: ou=Accounting, dc=airius, dc=com
../data/rfc/rfc2849.txt-
../data/rfc/rfc2849.txt-
../data/rfc/rfc2849.txt-
../data/rfc/rfc2849.txt-
../data/rfc/rfc2849.txt-Good Standards Track [Page 10]
--
../data/rfc/rfc8329.txt- components themselves. For example, the user can access a serial
../data/rfc/rfc8329.txt- console (most devices offer this interface for maintenance
../data/rfc/rfc8329.txt- reasons) to access the NSF software with the same level of
../data/rfc/rfc8329.txt- privilege of the provider.
../data/rfc/rfc8329.txt-
../data/rfc/rfc8329.txt: The use of authentication, authorization, accounting, and audit
../data/rfc/rfc8329.txt- mechanisms is recommended for all users and applications to access
../data/rfc/rfc8329.txt- the I2NSF environment. This can be further enhanced by requiring
../data/rfc/rfc8329.txt- attestation to be used to detect changes to the I2NSF environment by
../data/rfc/rfc8329.txt- authorized parties. The characteristics of these procedures will
../data/rfc/rfc8329.txt- define the level of assurance of the I2NSF environment.
--
../data/rfc/rfc8329.txt-
../data/rfc/rfc8329.txt- The network connection between the I2NSF Controller and NSFs will use
../data/rfc/rfc8329.txt- the trusted connection mechanisms described in Section 6.1.
../data/rfc/rfc8329.txt- Following these mechanisms, the connections need to rely on the use
../data/rfc/rfc8329.txt- of properly verified peer identities (e.g., through an
../data/rfc/rfc8329.txt: Authentication, Authorization, and Accounting (AAA) framework). The
../data/rfc/rfc8329.txt- implementations of identity management functions, as well as the AAA
../data/rfc/rfc8329.txt- framework, are out of scope for I2NSF.
../data/rfc/rfc8329.txt-
../data/rfc/rfc8329.txt-6.3. Interface to vNSFs
../data/rfc/rfc8329.txt-
--
../data/rfc/rfc8329.txt- +---------------+-------------------------------------------+
../data/rfc/rfc8329.txt- | Direction | Inbound, Outbound |
../data/rfc/rfc8329.txt- +---------------+-------------------------------------------+
../data/rfc/rfc8329.txt- | State | Authentication State |
../data/rfc/rfc8329.txt- | | Authorization State |
../data/rfc/rfc8329.txt: | | Accounting State |
../data/rfc/rfc8329.txt- | | Session State |
../data/rfc/rfc8329.txt- +---------------+-------------------------------------------+
../data/rfc/rfc8329.txt-
../data/rfc/rfc8329.txt- Note:
../data/rfc/rfc8329.txt- These fields are used to provide context information for
--
../data/rfc/rfc1758.txt- SD-9 Charter, Procedures and Operations of the
../data/rfc/rfc1758.txt- Central Administration for NADF
../data/rfc/rfc1758.txt- SD-10 Security & Privacy: Policy & Services
../data/rfc/rfc1758.txt- SD-11 Directory Security: Mechanisms and Practicality
../data/rfc/rfc1758.txt- SD-12 Registry of ADDMD Names
../data/rfc/rfc1758.txt: SD-13 NADF Accounting and Settlements
../data/rfc/rfc1758.txt-
../data/rfc/rfc1758.txt- SD-1 defines the scope of the NADF, whilst SD-2 describes issue of
../data/rfc/rfc1758.txt- interest to the NADF.
../data/rfc/rfc1758.txt-
../data/rfc/rfc1758.txt- The remaining documents describe the agreements necessary to achieve
--
../data/rfc/rfc1758.txt- specifies which mechanisms which will be used in the Public Directory
../data/rfc/rfc1758.txt- service.
../data/rfc/rfc1758.txt-
../data/rfc/rfc1758.txt- SD-12 provides a registry of ADDMD names in the NADF project.
../data/rfc/rfc1758.txt-
../data/rfc/rfc1758.txt: SD-13 provides a model and general principles for accounting and
../data/rfc/rfc1758.txt- settlement in the directory.
../data/rfc/rfc1758.txt-
../data/rfc/rfc1758.txt-1.1. Document Availability
../data/rfc/rfc1758.txt-
../data/rfc/rfc1758.txt- At the present time, the NADF standing documents are available only
--
../data/rfc/rfc4828.txt- 1. Introduction ....................................................3
../data/rfc/rfc4828.txt- 2. Conventions .....................................................5
../data/rfc/rfc4828.txt- 3. TFRC-SP Congestion Control ......................................5
../data/rfc/rfc4828.txt- 4. TFRC-SP Discussion ..............................................9
../data/rfc/rfc4828.txt- 4.1. Response Functions and Throughput Equations ................9
../data/rfc/rfc4828.txt: 4.2. Accounting for Header Size ................................12
../data/rfc/rfc4828.txt- 4.3. The TFRC-SP Min Interval ..................................13
../data/rfc/rfc4828.txt- 4.4. Counting Packet Losses ....................................14
../data/rfc/rfc4828.txt- 4.5. The Nominal Packet Size ...................................15
../data/rfc/rfc4828.txt- 4.5.1. Packet Size and Packet Drop Rates ..................15
../data/rfc/rfc4828.txt- 4.5.2. Fragmentation and the Path MTU .....................17
--
../data/rfc/rfc4828.txt- receiving the same packet drop rate.
../data/rfc/rfc4828.txt-
../data/rfc/rfc4828.txt- Simulations showing TCP, standard TFRC, and TFRC-SP sending rates in
../data/rfc/rfc4828.txt- response to a configured byte drop rate are given in Appendix B.2.
../data/rfc/rfc4828.txt-
../data/rfc/rfc4828.txt:4.2. Accounting for Header Size
../data/rfc/rfc4828.txt-
../data/rfc/rfc4828.txt- [RFC3714] makes the optimistic assumption that the limitation of the
../data/rfc/rfc4828.txt- network is in bandwidth in bytes per second (Bps), and not in CPU
../data/rfc/rfc4828.txt- cycles or in packets per second (pps). However, some attention must
../data/rfc/rfc4828.txt- be paid to the load in pps as well as to the load in Bps. Even aside
--
../data/rfc/rfc7296.txt- included in the two messages following the one containing the EAP
../data/rfc/rfc7296.txt- Success message.
../data/rfc/rfc7296.txt-
../data/rfc/rfc7296.txt- When the initiator authentication uses EAP, it is possible that the
../data/rfc/rfc7296.txt- contents of the IDi payload is used only for Authentication,
../data/rfc/rfc7296.txt: Authorization, and Accounting (AAA) routing purposes and selecting
../data/rfc/rfc7296.txt- which EAP method to use. This value may be different from the
../data/rfc/rfc7296.txt- identity authenticated by the EAP method. It is important that
../data/rfc/rfc7296.txt- policy lookups and access control decisions use the actual
../data/rfc/rfc7296.txt- authenticated identity. Often the EAP server is implemented in a
../data/rfc/rfc7296.txt- separate AAA server that communicates with the IKEv2 responder. In
--
../data/rfc/rfc7055.txt- methods are in wide use; one of EAP's strengths is that for most
../data/rfc/rfc7055.txt- types of credentials in common use, there is an EAP method that
../data/rfc/rfc7055.txt- permits the credential to be used.
../data/rfc/rfc7055.txt-
../data/rfc/rfc7055.txt- EAP is often used in conjunction with a backend Authentication,
../data/rfc/rfc7055.txt: Authorization and Accounting (AAA) server via RADIUS [RFC3579] or
../data/rfc/rfc7055.txt- Diameter [RFC4072]. In this mode, the Network Access Server (NAS)
../data/rfc/rfc7055.txt- simply tunnels EAP packets over the backend authentication protocol
../data/rfc/rfc7055.txt- to a home EAP/AAA server for the client. After EAP succeeds, the
../data/rfc/rfc7055.txt- backend authentication protocol is used to communicate key material
../data/rfc/rfc7055.txt- to the NAS. In this mode, the NAS need not be aware of or have any
--
../data/rfc/rfc5969.txt- and could be disruptive. As such, it is recommended that the service
../data/rfc/rfc5969.txt- provider assign CE IPv4 addresses with relatively long lifetimes.
../data/rfc/rfc5969.txt-
../data/rfc/rfc5969.txt- 6rd IPv6 address assignment, and hence the IPv6 service itself, is
../data/rfc/rfc5969.txt- tied to the IPv4 address lease; thus, the 6rd service is also tied to
../data/rfc/rfc5969.txt: this in terms of authorization, accounting, etc. For example, the
../data/rfc/rfc5969.txt- 6rd delegated prefix has the same lifetime as its associated IPv4
../data/rfc/rfc5969.txt- address. The prefix lifetimes advertised in Router Advertisements or
../data/rfc/rfc5969.txt- used by DHCP on the CE LAN side MUST be equal to or shorter than the
../data/rfc/rfc5969.txt- IPv4 address lease time. If the IPv4 lease time is not known, the
../data/rfc/rfc5969.txt- lifetime of the 6rd delegated prefix SHOULD follow the defaults
--
../data/rfc/rfc542.txt- the first command transmitted by the user after the TELNET
../data/rfc/rfc542.txt- connections are made (some servers may require this).
../data/rfc/rfc542.txt- Additional identification information in the form of a password
../data/rfc/rfc542.txt- and/or an account command may also be required by some servers.
../data/rfc/rfc542.txt- Servers may allow a new USER command to be entered at any point
../data/rfc/rfc542.txt: in order to change the access control and/or accounting
../data/rfc/rfc542.txt- information. This has the effect of flushing any user,
../data/rfc/rfc542.txt- password, and account information already supplied and
../data/rfc/rfc542.txt- beginning the login sequence again. All transfer parameters
../data/rfc/rfc542.txt- are unchanged and any file transfer in progress is completed
../data/rfc/rfc542.txt- under the old acccount.
--
../data/rfc/rfc542.txt-
../data/rfc/rfc542.txt- Change Working Directory (XCWD)
../data/rfc/rfc542.txt-
../data/rfc/rfc542.txt- This command allows the user to work with a different directory
../data/rfc/rfc542.txt- or dataset for file storage or retrieval without altering his
../data/rfc/rfc542.txt: login or accounting information. Transfer parameters are
../data/rfc/rfc542.txt- similarly unchanged. The argument is a pathname specifying a
../data/rfc/rfc542.txt- directory or other system dependent file group designator.
../data/rfc/rfc542.txt-
../data/rfc/rfc542.txt- FTP REPLIES
../data/rfc/rfc542.txt-
--
../data/rfc/rfc8869.txt- behavior of end-to-end real-time multimedia congestion control.
../data/rfc/rfc8869.txt-
../data/rfc/rfc8869.txt- Unless otherwise mentioned, the test cases in this section choose the
../data/rfc/rfc8869.txt- PHY- and MAC-layer parameters based on the IEEE 802.11n standard.
../data/rfc/rfc8869.txt- Statistics collected from enterprise Wi-Fi networks show that the two
../data/rfc/rfc8869.txt: dominant physical modes are 802.11n and 802.11ac, accounting for 41%
../data/rfc/rfc8869.txt- and 58% of connected devices, respectively. As Wi-Fi standards
../data/rfc/rfc8869.txt- evolve over time -- for instance, with the introduction of the
../data/rfc/rfc8869.txt- emerging Wi-Fi 6 (based on IEEE 802.11ax) products -- the PHY- and
../data/rfc/rfc8869.txt- MAC-layer test case specifications need to be updated accordingly to
../data/rfc/rfc8869.txt- reflect such changes.
--
../data/rfc/rfc5515.txt-
../data/rfc/rfc5515.txt- The L2TP AVPs defined in this document MAY be used with either an
../data/rfc/rfc5515.txt- L2TPv2 [RFC2661] or L2TPv3 [RFC3931] implementation.
../data/rfc/rfc5515.txt-
../data/rfc/rfc5515.txt- The information acquired may be used to provide authentication,
../data/rfc/rfc5515.txt: policy, and accounting functionality. It may also be collected and
../data/rfc/rfc5515.txt- used for management and troubleshooting purposes.
../data/rfc/rfc5515.txt-
../data/rfc/rfc5515.txt-2. Terminology
../data/rfc/rfc5515.txt-
../data/rfc/rfc5515.txt- The following sections define the usage and meaning of certain
--
../data/rfc/rfc820.txt- 72-149 110-225 Reserved [JBP]
../data/rfc/rfc820.txt- 150 226 Xerox NS IP [59,LLG]
../data/rfc/rfc820.txt- 151 227 Unassigned [JBP]
../data/rfc/rfc820.txt- 152 230 PARC Universal Protocol [4,EAT3]
../data/rfc/rfc820.txt- 153 231 TIP Status Reporting [JGH]
../data/rfc/rfc820.txt: 154 232 TIP Accounting [JGH]
../data/rfc/rfc820.txt- 155 233 Internet Protocol (regular) [33,62,JBP]
../data/rfc/rfc820.txt- 156-158 234-236 Internet Protocol (experimental) [33,62,JBP]
../data/rfc/rfc820.txt- 159-195 237-303 Unassigned [JBP]
../data/rfc/rfc820.txt- 196-255 304-377 Experimental Protocols [JBP]
../data/rfc/rfc820.txt- 248-255 370-377 Network Maintenance [JGH]
--
../data/rfc/rfc2940.txt- copsClientServerType CopsServerEntryType,
../data/rfc/rfc2940.txt- copsClientServerAuthType CopsAuthType,
../data/rfc/rfc2940.txt- copsClientServerLastConnAttempt TimeStamp,
../data/rfc/rfc2940.txt- copsClientState CopsClientState,
../data/rfc/rfc2940.txt- copsClientServerKeepaliveTime TimeInterval,
../data/rfc/rfc2940.txt: copsClientServerAccountingTime TimeInterval,
../data/rfc/rfc2940.txt- copsClientInPkts Counter32,
../data/rfc/rfc2940.txt- copsClientOutPkts Counter32,
../data/rfc/rfc2940.txt- copsClientInErrs Counter32,
../data/rfc/rfc2940.txt- copsClientLastError CopsErrorCode,
../data/rfc/rfc2940.txt- copsClientTcpConnectAttempts Counter32,
--
../data/rfc/rfc2940.txt- A value of zero indicates no keepalive activity is expected."
../data/rfc/rfc2940.txt- REFERENCE
../data/rfc/rfc2940.txt- "RFC 2748 section 3.7, 4.4"
../data/rfc/rfc2940.txt- ::= { copsClientServerCurrentEntry 9 }
../data/rfc/rfc2940.txt-
../data/rfc/rfc2940.txt:copsClientServerAccountingTime OBJECT-TYPE
../data/rfc/rfc2940.txt- SYNTAX TimeInterval
../data/rfc/rfc2940.txt- MAX-ACCESS read-only
../data/rfc/rfc2940.txt- STATUS current
../data/rfc/rfc2940.txt- DESCRIPTION
../data/rfc/rfc2940.txt: "The value of the COPS protocol Accounting timeout, in
../data/rfc/rfc2940.txt- centiseconds, currently in use by this client, as specified
../data/rfc/rfc2940.txt- by the COPS server in the Client-Accept operation. A value
../data/rfc/rfc2940.txt: of zero indicates no accounting activity is to be performed."
../data/rfc/rfc2940.txt- REFERENCE
../data/rfc/rfc2940.txt- "RFC 2748 section 3.7"
../data/rfc/rfc2940.txt- ::= { copsClientServerCurrentEntry 10 }
../data/rfc/rfc2940.txt-
../data/rfc/rfc2940.txt-copsClientInPkts OBJECT-TYPE
--
../data/rfc/rfc2940.txt- OBJECTS {
../data/rfc/rfc2940.txt- copsClientCapabilities,
../data/rfc/rfc2940.txt- copsClientServerTcpPort, copsClientServerType,
../data/rfc/rfc2940.txt- copsClientServerAuthType, copsClientServerLastConnAttempt,
../data/rfc/rfc2940.txt- copsClientState, copsClientServerKeepaliveTime,
../data/rfc/rfc2940.txt: copsClientServerAccountingTime, copsClientInPkts,
../data/rfc/rfc2940.txt- copsClientOutPkts, copsClientInErrs, copsClientLastError,
../data/rfc/rfc2940.txt- copsClientTcpConnectAttempts, copsClientTcpConnectFailures,
../data/rfc/rfc2940.txt- copsClientOpenAttempts, copsClientOpenFailures,
../data/rfc/rfc2940.txt- copsClientErrUnsupportClienttype,
../data/rfc/rfc2940.txt- copsClientErrUnsupportedVersion, copsClientErrLengthMismatch,
--
../data/rfc/rfc216.txt- Center Office, (805) 961- 2261).
../data/rfc/rfc216.txt-
../data/rfc/rfc216.txt-IV. System Access
../data/rfc/rfc216.txt-
../data/rfc/rfc216.txt- The Network user is encouraged to explore the System and is invited
../data/rfc/rfc216.txt: to do so with the following accounting parameters:
../data/rfc/rfc216.txt-
../data/rfc/rfc216.txt- User Number: 196
../data/rfc/rfc216.txt- Id Number: 57372
../data/rfc/rfc216.txt- User Name: ARPA
../data/rfc/rfc216.txt- Problem Name: (affiliation)-(name)
--
../data/rfc/rfc5778.txt- This document defines the home agent to the Diameter server
../data/rfc/rfc5778.txt- communication when the mobile node authenticates using the Internet
../data/rfc/rfc5778.txt- Key Exchange v2 protocol with the Extensible Authentication Protocol
../data/rfc/rfc5778.txt- or using the Mobile IPv6 Authentication Protocol. In addition to
../data/rfc/rfc5778.txt- authentication and authorization, the configuration of Mobile IPv6-
../data/rfc/rfc5778.txt: specific parameters and accounting is specified in this document.
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt-Status of This Memo
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt- This is an Internet Standards Track document.
../data/rfc/rfc5778.txt-
--
../data/rfc/rfc5778.txt- 4.3. Mobile IPv6 Session Management ............................11
../data/rfc/rfc5778.txt- 4.3.1. Session-Termination-Request ........................11
../data/rfc/rfc5778.txt- 4.3.2. Session-Termination-Answer .........................11
../data/rfc/rfc5778.txt- 4.3.3. Abort-Session-Request ..............................12
../data/rfc/rfc5778.txt- 4.3.4. Abort-Session-Answer ...............................12
../data/rfc/rfc5778.txt: 4.4. Accounting for Mobile IPv6 Services .......................12
../data/rfc/rfc5778.txt: 4.4.1. Accounting-Request .................................13
../data/rfc/rfc5778.txt: 4.4.2. Accounting-Answer ..................................13
../data/rfc/rfc5778.txt- 5. Command Codes ..................................................13
../data/rfc/rfc5778.txt- 5.1. Command Code for Mobile IPv6 with IKEv2 and EAP ...........13
../data/rfc/rfc5778.txt- 5.1.1. Diameter-EAP-Request ...............................13
../data/rfc/rfc5778.txt- 5.1.2. Diameter-EAP-Answer ................................14
../data/rfc/rfc5778.txt- 5.2. Command Codes for Mobile IPv6 Authentication
--
../data/rfc/rfc5778.txt- 6.16. MIP-Timestamp AVP ........................................25
../data/rfc/rfc5778.txt- 6.17. QoS-Capability AVP .......................................25
../data/rfc/rfc5778.txt- 6.18. QoS-Resources AVP ........................................25
../data/rfc/rfc5778.txt- 6.19. Chargeable-User-Identity AVP .............................25
../data/rfc/rfc5778.txt- 6.20. MIP6-Auth-Mode AVP .......................................25
../data/rfc/rfc5778.txt: 6.21. Accounting AVPs ..........................................26
../data/rfc/rfc5778.txt- 7. Result-Code AVP Values .........................................27
../data/rfc/rfc5778.txt- 7.1. Success ...................................................27
../data/rfc/rfc5778.txt- 7.2. Permanent Failures ........................................27
../data/rfc/rfc5778.txt- 8. AVP Occurrence Tables ..........................................27
../data/rfc/rfc5778.txt- 8.1. DER, DEA, MIR, and MIA AVP/Command-Code Table .............28
../data/rfc/rfc5778.txt: 8.2. Coupled Accounting Model AVP Table ........................28
../data/rfc/rfc5778.txt- 9. IANA Considerations ............................................29
../data/rfc/rfc5778.txt- 9.1. Command Codes .............................................29
../data/rfc/rfc5778.txt- 9.2. AVP Codes .................................................29
../data/rfc/rfc5778.txt- 9.3. Result-Code AVP Values ....................................30
../data/rfc/rfc5778.txt- 9.4. Application Identifier ....................................30
--
../data/rfc/rfc5778.txt- mobility in an MN without having to establish an IPsec SA with its
../data/rfc/rfc5778.txt- HA. Providing the collection of home address, HA address, and keying
../data/rfc/rfc5778.txt- material is generally referred to as the Mobile IPv6 bootstrapping
../data/rfc/rfc5778.txt- problem [RFC4640]. The purpose of this specification is to provide
../data/rfc/rfc5778.txt- Diameter support for the interaction between the HA and the
../data/rfc/rfc5778.txt: Authentication, Authorization, and Accounting (AAA) server. This
../data/rfc/rfc5778.txt- specification satisfies the requirements defined in [RFC5637] for the
../data/rfc/rfc5778.txt- bootstrapping problem in the split scenario [RFC5026] and also
../data/rfc/rfc5778.txt- specifies Diameter support for the Authentication Protocol for Mobile
../data/rfc/rfc5778.txt- IPv6 [RFC4285]. The Diameter support defined in this specification
../data/rfc/rfc5778.txt- also applies to Dual Stack Mobile IPv6 [RFC5555].
--
../data/rfc/rfc5778.txt- Mobile IPv6 parameters. Thus, prior to processing the Mobile IPv6
../data/rfc/rfc5778.txt- registrations, the HA participates in the authentication of the MN to
../data/rfc/rfc5778.txt- verify the MN's identity. The HA also participates in the Mobile
../data/rfc/rfc5778.txt- IPv6 authorization process involving the Diameter infrastructure.
../data/rfc/rfc5778.txt- The HA, due to its role in traffic forwarding, may also perform
../data/rfc/rfc5778.txt: accounting for the Mobile IPv6 service provided to the MN.
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt- This document enables the following functionality:
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt- Authentication: The MN's identity needs to be verified. As a
../data/rfc/rfc5778.txt- Diameter client supporting the new Diameter Mobile IPv6
--
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt- authorization decisions. This document defines required AAA
../data/rfc/rfc5778.txt- procedures and requires the HA to support them and to participate
../data/rfc/rfc5778.txt- in this authorization signaling.
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt: Accounting: For accounting purposes and capacity planning, it is
../data/rfc/rfc5778.txt: required that the HA provides accounting reports to the Diameter
../data/rfc/rfc5778.txt: infrastructure and thus supports the related Diameter accounting
../data/rfc/rfc5778.txt- procedures.
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt- Session Management: The management of the mobility services may
../data/rfc/rfc5778.txt- require the Diameter server or the HA to terminate the Mobile IPv6
../data/rfc/rfc5778.txt- service before the binding expires. This document defines
--
../data/rfc/rfc5778.txt- o Mobile IPv6 Authentication Protocol
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt- New authentication mechanisms may be added later by separate
../data/rfc/rfc5778.txt- specifications.
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt: For accounting of Mobile IPv6 services provided to the MN, this
../data/rfc/rfc5778.txt: specification uses the Diameter base protocol accounting defined in
../data/rfc/rfc5778.txt- [RFC3588].
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt-2. Terminology
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
--
../data/rfc/rfc5778.txt- document are to be interpreted as described in [RFC2119].
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt- The Mobile IPv6 bootstrapping terminology is taken from [RFC4640].
../data/rfc/rfc5778.txt- Additional terminology is defined below:
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt: Authentication, Authorization, and Accounting (AAA):
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt- AAA protocol based on Diameter [RFC3588] with required EAP support
../data/rfc/rfc5778.txt- [RFC4072].
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt- Home AAA (AAAH):
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt: An authentication, authorization, and accounting server located in
../data/rfc/rfc5778.txt- the user's home network, i.e., in the home realm.
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt-3. Application Identifiers
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt- This specification defines two new Diameter applications and their
--
../data/rfc/rfc5778.txt-Korhonen, et al. Standards Track [Page 6]
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt-RFC 5778 Diameter MIPv6: HA-to-AAAH Support February 2010
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt: Mobile IPv6-related accounting information generated by the HA uses
../data/rfc/rfc5778.txt- either the MIP6I or the MIP6A Application Identifier in the case of
../data/rfc/rfc5778.txt: the coupled accounting model. The Diameter Base Accounting
../data/rfc/rfc5778.txt- Application Identifier (value of 3) is used in the case of the split
../data/rfc/rfc5778.txt: accounting model. Refer to Section 4.4 for more information
../data/rfc/rfc5778.txt: regarding the accounting models.
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt-4. Protocol Description
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt-4.1. Support for Mobile IPv6 with IKEv2 and EAP
../data/rfc/rfc5778.txt-
--
../data/rfc/rfc5778.txt- can then indicate the preferred responder type using the appropriate
../data/rfc/rfc5778.txt- IDr payload in the IKE_AUTH message.
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt- Eventually, when the HA receives a Binding Update (BU), the HA
../data/rfc/rfc5778.txt- authenticates and authorizes the MN. It is RECOMMENDED that the HA
../data/rfc/rfc5778.txt: sends an accounting request message every time it receives a BU.
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt-
--
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt- The procedure described in this specification for the Mobile IPv6
../data/rfc/rfc5778.txt- Authentication Protocol is only needed for the initially received BU
../data/rfc/rfc5778.txt- for which the HA does not have an existing security association.
../data/rfc/rfc5778.txt- When the HA receives subsequent BUs, they are processed locally in
../data/rfc/rfc5778.txt: the HA. It is RECOMMENDED that the HA sends an accounting request
../data/rfc/rfc5778.txt- message every time it receives a Binding Update. However, the HA MAY
../data/rfc/rfc5778.txt- re-authorize the MN with the Diameter server at any time depending on
../data/rfc/rfc5778.txt- the deployment and the local policy.
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt- This specification assumes that in the case where Mobile IPv6
--
../data/rfc/rfc5778.txt-4.3.4. Abort-Session-Answer
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt- The Abort-Session-Answer (ASA) message [RFC3588] is sent by the home
../data/rfc/rfc5778.txt- agent in response to an ASR message.
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt:4.4. Accounting for Mobile IPv6 Services
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt: The HA MUST be able act as a Diameter client collecting accounting
../data/rfc/rfc5778.txt- records needed for service control and charging. The HA MUST support
../data/rfc/rfc5778.txt: the accounting procedures (specifically the command codes mentioned
../data/rfc/rfc5778.txt: below) and the Accounting Session State Machine as defined in
../data/rfc/rfc5778.txt- [RFC3588]. The command codes, exchanged between the HA and Diameter
../data/rfc/rfc5778.txt: server for accounting purposes, are provided in the following
../data/rfc/rfc5778.txt- subsections.
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt- The Diameter application design guideline [DIME-APP] defines two
../data/rfc/rfc5778.txt: separate models for accounting:
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt: Split accounting model:
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt: According to this model, the accounting messages use the Diameter
../data/rfc/rfc5778.txt: Base Accounting Application Identifier (value of 3). Since
../data/rfc/rfc5778.txt: accounting is treated as an independent application, accounting
../data/rfc/rfc5778.txt- commands may be routed separately from the rest of application
../data/rfc/rfc5778.txt: messages and thus the accounting messages generally end up in a
../data/rfc/rfc5778.txt: central accounting server. Since the Diameter Mobile IPv6
../data/rfc/rfc5778.txt: application does not define its own unique accounting commands,
../data/rfc/rfc5778.txt- this is the preferred choice, since it permits use of centralized
../data/rfc/rfc5778.txt: accounting for several applications.
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt: Coupled accounting model:
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt: In this model, the accounting messages will use either the MIP6I
../data/rfc/rfc5778.txt: or the MIP6A Application Identifiers. This means that accounting
../data/rfc/rfc5778.txt- messages will be routed like any other Mobile IPv6 application
../data/rfc/rfc5778.txt- messages. This requires the Diameter server in charge of Mobile
../data/rfc/rfc5778.txt: IPv6 application to handle the accounting records (e.g., sends
../data/rfc/rfc5778.txt: them to a proper accounting server).
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt-Korhonen, et al. Standards Track [Page 12]
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt-RFC 5778 Diameter MIPv6: HA-to-AAAH Support February 2010
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt- As mentioned above, the preferred choice is to use the split
../data/rfc/rfc5778.txt: accounting model and thus to choose Diameter Base Accounting
../data/rfc/rfc5778.txt: Application Identifier (value of 3) for accounting messages.
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt:4.4.1. Accounting-Request
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt: The Accounting-Request command [RFC3588] is sent by the HA to the
../data/rfc/rfc5778.txt: Diameter server to exchange accounting information regarding the MN
../data/rfc/rfc5778.txt- with the Diameter server.
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt:4.4.2. Accounting-Answer
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt: The Accounting-Answer command [RFC3588] is sent by the Diameter
../data/rfc/rfc5778.txt: server to the HA to acknowledge an Accounting-Request.
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt-5. Command Codes
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt-5.1. Command Code for Mobile IPv6 with IKEv2 and EAP
../data/rfc/rfc5778.txt-
--
../data/rfc/rfc5778.txt- If the Diameter server does not support the Mobile IPv6
../data/rfc/rfc5778.txt- Authentication Protocol usage mode proposed by the HA, then the
../data/rfc/rfc5778.txt- Diameter server MUST fail the authentication/authorization and MUST
../data/rfc/rfc5778.txt- set the Result-Code AVP to the value of DIAMETER_ERROR_AUTH_MODE.
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt:6.21. Accounting AVPs
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt- Diameter Mobile IPv6 applications, either MIP6I or MIP6A, are used in
../data/rfc/rfc5778.txt- the case of the coupled account model. Diameter Mobile IPv4
../data/rfc/rfc5778.txt: application [RFC4004] accounting AVPs are reused in this document.
../data/rfc/rfc5778.txt: The following AVPs SHOULD be included in the accounting request
../data/rfc/rfc5778.txt- message:
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt: o Accounting-Input-Octets: Number of octets in IP packets received
../data/rfc/rfc5778.txt- from the mobile node.
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt: o Accounting-Output-Octets: Number of octets in IP packets sent by
../data/rfc/rfc5778.txt- the mobile node.
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt: o Accounting-Input-Packets: Number of IP packets received from the
../data/rfc/rfc5778.txt- mobile node.
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt: o Accounting-Output-Packets: Number of IP packets sent by the mobile
../data/rfc/rfc5778.txt- node.
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt- o Acct-Multi-Session-Id: Used to link together multiple related
../data/rfc/rfc5778.txt: accounting sessions, where each session would have a unique
../data/rfc/rfc5778.txt- Session-Id, but the same Acct-Multi-Session-Id AVP.
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt- o Acct-Session-Time: Indicates the length of the current session in
../data/rfc/rfc5778.txt- seconds.
../data/rfc/rfc5778.txt-
--
../data/rfc/rfc5778.txt- QoS-Capability | 0-1 | 0 | 0-1 | 0 |
../data/rfc/rfc5778.txt- Chargeable-User-Identity | 0-1 | 0-1 | 0-1 | 0-1 |
../data/rfc/rfc5778.txt- MIP6-Auth-Mode | 0 | 0 | 1 | 0 |
../data/rfc/rfc5778.txt- +-----+-----+-----+-----+
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt:8.2. Coupled Accounting Model AVP Table
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt- The table in this section is used to represent which AVPs defined in
../data/rfc/rfc5778.txt: this document are to be present in the Accounting messages, as
../data/rfc/rfc5778.txt- defined in [RFC3588].
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt-
--
../data/rfc/rfc5778.txt- +-------------+
../data/rfc/rfc5778.txt- | Command-Code|
../data/rfc/rfc5778.txt- |------+------+
../data/rfc/rfc5778.txt- Attribute Name | ACR | ACA |
../data/rfc/rfc5778.txt- -------------------------------------|------+------+
../data/rfc/rfc5778.txt: Accounting-Input-Octets | 0-1 | 0-1 |
../data/rfc/rfc5778.txt: Accounting-Input-Packets | 0-1 | 0-1 |
../data/rfc/rfc5778.txt: Accounting-Output-Octets | 0-1 | 0-1 |
../data/rfc/rfc5778.txt: Accounting-Output-Packets | 0-1 | 0-1 |
../data/rfc/rfc5778.txt- Acct-Multi-Session-Id | 0-1 | 0-1 |
../data/rfc/rfc5778.txt- Acct-Session-Time | 0-1 | 0-1 |
../data/rfc/rfc5778.txt- MIP6-Feature-Vector | 0-1 | 0-1 |
../data/rfc/rfc5778.txt- MIP6-Agent-Info | 0-1 | 0-1 |
../data/rfc/rfc5778.txt- MIP-Mobile-Node-Address | 0-2 | 0-2 |
--
../data/rfc/rfc5778.txt- [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts
../data/rfc/rfc5778.txt- and Routers", RFC 5555, June 2009.
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt- [RFC5637] Giaretta, G., Guardini, I., Demaria, E., Bournelle, J.,
../data/rfc/rfc5778.txt- and R. Lopez, "Authentication, Authorization, and
../data/rfc/rfc5778.txt: Accounting (AAA) Goals for Mobile IPv6", RFC 5637,
../data/rfc/rfc5778.txt- September 2009.
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt-
../data/rfc/rfc5778.txt-Korhonen, et al. Standards Track [Page 33]
--
../data/rfc/rfc1281.txt- 20510, October 1987.
../data/rfc/rfc1281.txt-
../data/rfc/rfc1281.txt- [16] "Summary of General Legislation Relating to Privacy and Computer
../data/rfc/rfc1281.txt- Security", Appendix 1 of, COMPUTERS and PRIVACY: How the
../data/rfc/rfc1281.txt- Government Obtains, Verifies, Uses and Protects Personal Data,
../data/rfc/rfc1281.txt: GAO/IMTEC-90-70BR, United States General Accounting Office,
../data/rfc/rfc1281.txt- Washington, DC 20548, pp. 36-40, August 1990.
../data/rfc/rfc1281.txt-
../data/rfc/rfc1281.txt- [17] Stout, E., "U.S. Geological Survey System Security Plan - FY
../data/rfc/rfc1281.txt- 1990", U.S. Geological Survey ISD, MS809, Reston, VA, 22092, May
../data/rfc/rfc1281.txt- 1990.
--
../data/rfc/rfc7491.txt- capability.
../data/rfc/rfc7491.txt-
../data/rfc/rfc7491.txt- - Client microflows should not trigger server-layer setup or
../data/rfc/rfc7491.txt- allocation.
../data/rfc/rfc7491.txt-
../data/rfc/rfc7491.txt: - Accounting capabilities should be supported.
../data/rfc/rfc7491.txt-
../data/rfc/rfc7491.txt- - Security mechanisms for authorization of requests and capabilities
../data/rfc/rfc7491.txt- are required.
../data/rfc/rfc7491.txt-
../data/rfc/rfc7491.txt- Other policy-related functionality in the system might include the
--
../data/rfc/rfc1812.txt- an essential part of any router implementation. Although these
../data/rfc/rfc1812.txt- functions do not seem to relate directly to interoperability, they
../data/rfc/rfc1812.txt- are essential to the network manager who must make the router
../data/rfc/rfc1812.txt- interoperate and must track down problems when it doesn't. This
../data/rfc/rfc1812.txt- chapter also includes some discussion of router initialization and of
../data/rfc/rfc1812.txt: facilities to assist network managers in securing and accounting for
../data/rfc/rfc1812.txt- their networks.
../data/rfc/rfc1812.txt-
../data/rfc/rfc1812.txt-10.1 Introduction
../data/rfc/rfc1812.txt-
../data/rfc/rfc1812.txt- The following kinds of activities are included under router O&M:
--
../data/rfc/rfc1812.txt-Baker Standards Track [Page 131]
../data/rfc/rfc1812.txt-
../data/rfc/rfc1812.txt-RFC 1812 Requirements for IP Version 4 Routers June 1995
../data/rfc/rfc1812.txt-
../data/rfc/rfc1812.txt-
../data/rfc/rfc1812.txt: (2) Packet Accounting
../data/rfc/rfc1812.txt-
../data/rfc/rfc1812.txt- Vendors should strongly consider providing a system for
../data/rfc/rfc1812.txt- tracking traffic levels between pairs of hosts or networks.
../data/rfc/rfc1812.txt- A mechanism for limiting the collection of this information
../data/rfc/rfc1812.txt- to specific pairs of hosts or networks is also strongly
--
../data/rfc/rfc3000.txt-WEBDAV HTTP Extensions for Distributed Authoring -- WEBDAV 2518
../data/rfc/rfc3000.txt-ATM-MIBMAN Definitions of Managed Objects for ATM Management 2515
../data/rfc/rfc3000.txt-ATM-TC-OID Definitions of Textual Conventions and OBJECT- 2514
../data/rfc/rfc3000.txt- IDENTITIES for ATM Management
../data/rfc/rfc3000.txt--------- Managed Objects for Controlling the Collection 2513
../data/rfc/rfc3000.txt: and Storage of Accounting Information for
../data/rfc/rfc3000.txt- Connection-Oriented Networks
../data/rfc/rfc3000.txt:-------- Accounting Information for ATM Networks 2512
../data/rfc/rfc3000.txt-
../data/rfc/rfc3000.txt-
../data/rfc/rfc3000.txt-
../data/rfc/rfc3000.txt-IETF Standards Track [Page 21]
../data/rfc/rfc3000.txt-
--
../data/rfc/rfc5193.txt-RFC 5193 PANA Framework May 2008
../data/rfc/rfc5193.txt-
../data/rfc/rfc5193.txt-
../data/rfc/rfc5193.txt- enables the authentication process between the two entities, it is
../data/rfc/rfc5193.txt- only a part of an overall AAA (Authentication, Authorization and
../data/rfc/rfc5193.txt: Accounting) and access control framework. A AAA and access control
../data/rfc/rfc5193.txt- framework using PANA is comprised of four functional entities.
../data/rfc/rfc5193.txt-
../data/rfc/rfc5193.txt- Figure 1 illustrates these functional entities and the interfaces
../data/rfc/rfc5193.txt- (protocols, APIs) among them.
../data/rfc/rfc5193.txt-
--
../data/rfc/rfc7323.txt- calculated by the RTO mechanism in [RFC6298], and the below algorithm
../data/rfc/rfc7323.txt- aims to maintain a similar history as originally intended by
../data/rfc/rfc7323.txt- [RFC6298].
../data/rfc/rfc7323.txt-
../data/rfc/rfc7323.txt- It is roughly known how many samples a congestion window worth of
../data/rfc/rfc7323.txt: data will yield, not accounting for ACK compression, and ACK losses.
../data/rfc/rfc7323.txt- Such events will result in more history of the path being reflected
../data/rfc/rfc7323.txt- in the final value for RTO, and are uncritical. This modification
../data/rfc/rfc7323.txt- will ensure that a similar amount of time is taken into account for
../data/rfc/rfc7323.txt- the RTO estimation, regardless of how many samples are taken per
../data/rfc/rfc7323.txt- window:
--
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt- This document provides a printer industry standard SNMP MIB for (1)
../data/rfc/rfc2707.txt- monitoring the status and progress of print jobs (2) obtaining
../data/rfc/rfc2707.txt- resource requirements before a job is processed, (3) monitoring
../data/rfc/rfc2707.txt- resource consumption while a job is being processed and (4)
../data/rfc/rfc2707.txt: collecting resource accounting data after the completion of a job.
../data/rfc/rfc2707.txt- This MIB is intended to be implemented (1) in a printer or (2) in a
../data/rfc/rfc2707.txt- server that supports one or more printers. Use of the object set is
../data/rfc/rfc2707.txt- not limited to printing. However, support for services other than
../data/rfc/rfc2707.txt- printing is outside the scope of this Job Monitoring MIB. Future
../data/rfc/rfc2707.txt-
--
../data/rfc/rfc2707.txt- it would be running for a long period of time and may also be
../data/rfc/rfc2707.txt- interested in the jobs that have completed. Finally such a
../data/rfc/rfc2707.txt- program may be used to provide an enhanced console and
../data/rfc/rfc2707.txt- logging capability.
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt: 3. Collect resource usage for accounting or system utilization
../data/rfc/rfc2707.txt- purposes that copy the completed job statistics to an
../data/rfc/rfc2707.txt: accounting system. It is recognized that depending on
../data/rfc/rfc2707.txt: accounting programs to copy MIB data during the job-retention
../data/rfc/rfc2707.txt: period is somewhat unreliable, since the accounting program
../data/rfc/rfc2707.txt- may not be running (or may have crashed). Such a program is
../data/rfc/rfc2707.txt- also expected to keep a shadow copy of the entire Job
../data/rfc/rfc2707.txt- Attribute table including completed, canceled, and aborted
../data/rfc/rfc2707.txt- jobs which the program updates on each polling cycle. Such a
../data/rfc/rfc2707.txt- program polls at the rate of the persistence of the Attribute
--
../data/rfc/rfc2707.txt- drawn from the ISO 10175 Document Printing Application (DPA)
../data/rfc/rfc2707.txt- standard [iso-dpa]. For example, PostScript systems use the term
../data/rfc/rfc2707.txt- session for what is called a job in this specification and the
../data/rfc/rfc2707.txt- term job to mean what is called a document in this specification.
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt: Accounting Application: The SNMP management application that copies
../data/rfc/rfc2707.txt- job information to some more permanent medium so that another
../data/rfc/rfc2707.txt: application can perform accounting on the data for Accountants, Asset
../data/rfc/rfc2707.txt- Managers, and Capacity Planners use.
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt- Agent: The network entity that accepts SNMP requests from a monitor
../data/rfc/rfc2707.txt: or accounting application and provides access to the instrumentation
../data/rfc/rfc2707.txt- for managing jobs modeled by the management objects defined in the
../data/rfc/rfc2707.txt- Job Monitoring MIB module for a server or a device.
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt- Attribute: A name, value-pair that specifies a job or document
../data/rfc/rfc2707.txt- instruction, a status, or a condition of a job or a document that has
--
../data/rfc/rfc2707.txt- the marker marks on both sides of a sheet in a single pass. Two-up
../data/rfc/rfc2707.txt- printing is the placement of two logical pages on one side of a sheet
../data/rfc/rfc2707.txt- and so is still a single impression. See "page" and "sheet".
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt- NOTE - Since impressions include blank sides, it is suggested that
../data/rfc/rfc2707.txt: accounting application implementers consider charging for sheets,
../data/rfc/rfc2707.txt- rather than impressions, possibly using the value of the sides
../data/rfc/rfc2707.txt- attribute to select different charges for one-sided versus two-sided
../data/rfc/rfc2707.txt- printing, since some users may think that impressions don't include
../data/rfc/rfc2707.txt- blank sides.
../data/rfc/rfc2707.txt-
--
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt- Job: A unit of work whose results are expected together without
../data/rfc/rfc2707.txt- interjection of unrelated results. A job contains one or more
../data/rfc/rfc2707.txt- documents.
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt: Job Accounting: The activity of a management application of
../data/rfc/rfc2707.txt- accessing the MIB and recording what happens to the job during and
../data/rfc/rfc2707.txt- after the processing of the job.
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt- Job Instruction: An instruction specifying how, when, or where the
../data/rfc/rfc2707.txt- job is to be processed. Job instructions MAY be passed in the job
--
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt- The job submitting client and/or monitoring application monitor jobs
../data/rfc/rfc2707.txt- by communicating directly with an agent that is part of the printer.
../data/rfc/rfc2707.txt- The agent in the printer SHALL keep the job in the Job Monitoring MIB
../data/rfc/rfc2707.txt- as long as the job is in the printer, plus a defined time period
../data/rfc/rfc2707.txt: after the job enters the completed state in which accounting programs
../data/rfc/rfc2707.txt: can copy out the accounting data from the Job Monitoring MIB.
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt- all end-user ######## SNMP query
../data/rfc/rfc2707.txt- +-------+ +--------+ ---- job submission
../data/rfc/rfc2707.txt- |monitor| | client |
../data/rfc/rfc2707.txt- +---#---+ +--#--+--+
--
../data/rfc/rfc2707.txt- jobs that the server has submitted to the printer. The Job
../data/rfc/rfc2707.txt- Monitoring MIB agent obtains the required information from the
../data/rfc/rfc2707.txt- printer by a method that is beyond the scope of this document. The
../data/rfc/rfc2707.txt- agent in the server SHALL keep the job in the Job Monitoring MIB in
../data/rfc/rfc2707.txt- the server as long as the job is in the printer, plus a defined time
../data/rfc/rfc2707.txt: period after the job enters the completed state in which accounting
../data/rfc/rfc2707.txt: programs can copy out the accounting data from the Job Monitoring
../data/rfc/rfc2707.txt- MIB.
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt- all end-user
../data/rfc/rfc2707.txt- +-------+ +----------+
../data/rfc/rfc2707.txt- |monitor| | client | ######## SNMP query
--
../data/rfc/rfc2707.txt- the document data, or by direct query of the server), in order to
../data/rfc/rfc2707.txt- populate some of the objects the Job Monitoring MIB in the printer.
../data/rfc/rfc2707.txt- The agent in the printer SHALL keep the job in the Job Monitoring MIB
../data/rfc/rfc2707.txt- as long as the job is in the Printer, and longer in order to
../data/rfc/rfc2707.txt- implement the completed state in which monitoring programs can copy
../data/rfc/rfc2707.txt: out the accounting data from the Job Monitoring MIB.
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt-
--
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
../data/rfc/rfc2707.txt- + Job Identification attributes (20 - 49 decimal)
../data/rfc/rfc2707.txt- +
../data/rfc/rfc2707.txt- + The following attributes help an end user, a system
../data/rfc/rfc2707.txt: + operator, or an accounting program identify a job.
../data/rfc/rfc2707.txt- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt- jobURI(20), OCTET STRING(SIZE(0..63))
../data/rfc/rfc2707.txt- OCTETS: MULTI-ROW: The job's Universal Resource
../data/rfc/rfc2707.txt- Identifier (URI) [RFC1738]. See IPP [ipp-model] for
--
../data/rfc/rfc2707.txt- no maximum length.
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt- jobAccountName(21), OCTET STRING(SIZE(0..63))
../data/rfc/rfc2707.txt- OCTETS: Arbitrary binary information which MAY be coded
../data/rfc/rfc2707.txt- character set data or encrypted data supplied by the
../data/rfc/rfc2707.txt: submitting user for use by accounting services to allocate
../data/rfc/rfc2707.txt- or categorize charges for services provided, such as a
../data/rfc/rfc2707.txt- customer account name or number.
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt- NOTE: This attribute NEED NOT be printable characters.
../data/rfc/rfc2707.txt-
--
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt-RFC 2707 Job Monitoring MIB - V1.0 November 1999
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt- postProcessingFailed 0x8
../data/rfc/rfc2707.txt: The post-processing agent failed while trying to log accounting
../data/rfc/rfc2707.txt- attributes for the job; therefore the job has been placed into
../data/rfc/rfc2707.txt- the completed state with the jobRetained jmJobStateReasons1
../data/rfc/rfc2707.txt- object value for a system-defined period of time, so the
../data/rfc/rfc2707.txt- administrator can examine it, resubmit it, etc.
../data/rfc/rfc2707.txt-
--
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt- Configuring this object is implementation-dependent.
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt- This value SHALL be equal to or greater than the value of
../data/rfc/rfc2707.txt- jmGeneralAttributePersistence. This value SHOULD be at least
../data/rfc/rfc2707.txt: 60 which gives a monitoring or accounting application one
../data/rfc/rfc2707.txt- minute in which to poll for job data."
../data/rfc/rfc2707.txt- DEFVAL { 60 } -- one minute
../data/rfc/rfc2707.txt- ::= { jmGeneralEntry 5 }
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt-
--
../data/rfc/rfc2707.txt- when the job enters the completed, canceled, or aborted state.
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt- Configuring this object is implementation-dependent.
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt- This value SHOULD be at least 60 which gives a monitoring or
../data/rfc/rfc2707.txt: accounting application one minute in which to poll for job
../data/rfc/rfc2707.txt- data."
../data/rfc/rfc2707.txt- DEFVAL { 60 } -- one minute
../data/rfc/rfc2707.txt- ::= { jmGeneralEntry 6 }
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt-
--
../data/rfc/rfc2707.txt- completes processing, i.e., this value SHALL indicate the total
../data/rfc/rfc2707.txt- usage of this resource made by the job.
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt- A monitoring application is able to copy this value to a
../data/rfc/rfc2707.txt- suitable longer term storage for later processing as part of an
../data/rfc/rfc2707.txt: accounting system.
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt- Since the agent MAY add attributes representing resources to
../data/rfc/rfc2707.txt- this table while the job is waiting to be processed or being
../data/rfc/rfc2707.txt- processed, which can be a long time before any of the resources
../data/rfc/rfc2707.txt- are actually used, the agent SHALL set the value of the
--
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt- Job states are intended to last a user-visible length of time in most
../data/rfc/rfc2707.txt- implementations. However, some jobs may pass through some states in
../data/rfc/rfc2707.txt- zero time in some situations and/or in some implementations.
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt: The job model does not specify how accounting and auditing is
../data/rfc/rfc2707.txt: implemented, except to assume that accounting and auditing logs are
../data/rfc/rfc2707.txt- separate from the job life cycle and last longer than job entries in
../data/rfc/rfc2707.txt- the MIB. Jobs in the completed, aborted, or canceled states are not
../data/rfc/rfc2707.txt- logs, since jobs in these states are accessible via SNMP protocol
../data/rfc/rfc2707.txt- operations and SHALL be removed from the Job Monitoring MIB tables
../data/rfc/rfc2707.txt- after a site-settable or implementation-defined period of time. An
../data/rfc/rfc2707.txt: accounting application MAY copy accounting information incrementally
../data/rfc/rfc2707.txt: to an accounting log as a job processes, or MAY be copied while the
../data/rfc/rfc2707.txt- job is in the canceled, aborted, or completed states, depending on
../data/rfc/rfc2707.txt- implementation. The same is true for auditing logs.
../data/rfc/rfc2707.txt-
../data/rfc/rfc2707.txt- The jmJobState object specifies the standard job states. The normal
../data/rfc/rfc2707.txt- job state transitions are shown in the state transition diagram
--
../data/rfc/rfc2799.txt-
../data/rfc/rfc2799.txt-This document provides a printer industry standard SNMP MIB for (1)
../data/rfc/rfc2799.txt-monitoring the status and progress of print jobs (2) obtaining resource
../data/rfc/rfc2799.txt-requirements before a job is processed, (3) monitoring resource
../data/rfc/rfc2799.txt-consumption while a job is being processed and (4) collecting resource
../data/rfc/rfc2799.txt:accounting data after the completion of a job. This memo provides
../data/rfc/rfc2799.txt-information for the Internet community.
../data/rfc/rfc2799.txt-
../data/rfc/rfc2799.txt-
../data/rfc/rfc2799.txt-2706 Eastlake Oct 1999 ECML v1: Field Names for
../data/rfc/rfc2799.txt- E-Commerce
--
../data/rfc/rfc5533.txt-11. Sending ULP Payloads
../data/rfc/rfc5533.txt-
../data/rfc/rfc5533.txt- When there is no context state for the ULID pair on the sender, there
../data/rfc/rfc5533.txt- is no effect on how ULP packets are sent. If the host is using some
../data/rfc/rfc5533.txt- heuristic for determining when to perform a deferred context
../data/rfc/rfc5533.txt: establishment, then the host might need to do some accounting (count
../data/rfc/rfc5533.txt- the number of packets sent and received) even before there is a ULID-
../data/rfc/rfc5533.txt- pair context.
../data/rfc/rfc5533.txt-
../data/rfc/rfc5533.txt-
../data/rfc/rfc5533.txt-
--
../data/rfc/rfc5533.txt- the Next Header value (which might be some function associated with
../data/rfc/rfc5533.txt- the IP endpoint sublayer or a ULP).
../data/rfc/rfc5533.txt-
../data/rfc/rfc5533.txt- If the host is using some heuristic for determining when to perform a
../data/rfc/rfc5533.txt- deferred context establishment, then the host might need to do some
../data/rfc/rfc5533.txt: accounting (count the number of packets sent and received) for
../data/rfc/rfc5533.txt- packets that do not have a Shim6 Extension header and for which there
../data/rfc/rfc5533.txt- is no context. But the need for this depends on what heuristics the
../data/rfc/rfc5533.txt- implementation has chosen.
../data/rfc/rfc5533.txt-
../data/rfc/rfc5533.txt-12.3. Receiving Shim Control Messages
--
../data/rfc/rfc2866.txt-Request for Comments: 2866 Livingston
../data/rfc/rfc2866.txt-Category: Informational June 2000
../data/rfc/rfc2866.txt-Obsoletes: 2139
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: RADIUS Accounting
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Status of this Memo
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- This memo provides information for the Internet community. It does
../data/rfc/rfc2866.txt- not specify an Internet standard of any kind. Distribution of this
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Copyright (C) The Internet Society (2000). All Rights Reserved.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Abstract
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: This document describes a protocol for carrying accounting
../data/rfc/rfc2866.txt: information between a Network Access Server and a shared Accounting
../data/rfc/rfc2866.txt- Server.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Implementation Note
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: This memo documents the RADIUS Accounting protocol. The early
../data/rfc/rfc2866.txt: deployment of RADIUS Accounting was done using UDP port number 1646,
../data/rfc/rfc2866.txt- which conflicts with the "sa-msg-port" service. The officially
../data/rfc/rfc2866.txt: assigned port number for RADIUS Accounting is 1813.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Table of Contents
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- 1. Introduction .................................... 2
../data/rfc/rfc2866.txt- 1.1 Specification of Requirements ................. 3
../data/rfc/rfc2866.txt- 1.2 Terminology ................................... 3
../data/rfc/rfc2866.txt- 2. Operation ....................................... 4
../data/rfc/rfc2866.txt- 2.1 Proxy ......................................... 4
../data/rfc/rfc2866.txt- 3. Packet Format ................................... 5
../data/rfc/rfc2866.txt- 4. Packet Types ................................... 7
../data/rfc/rfc2866.txt: 4.1 Accounting-Request ............................ 8
../data/rfc/rfc2866.txt: 4.2 Accounting-Response ........................... 9
../data/rfc/rfc2866.txt- 5. Attributes ...................................... 10
../data/rfc/rfc2866.txt- 5.1 Acct-Status-Type .............................. 12
../data/rfc/rfc2866.txt- 5.2 Acct-Delay-Time ............................... 13
../data/rfc/rfc2866.txt- 5.3 Acct-Input-Octets ............................. 14
../data/rfc/rfc2866.txt- 5.4 Acct-Output-Octets ............................ 15
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Rigney Informational [Page 1]
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt:RFC 2866 RADIUS Accounting June 2000
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- 5.6 Acct-Authentic ................................ 16
../data/rfc/rfc2866.txt- 5.7 Acct-Session-Time ............................. 17
../data/rfc/rfc2866.txt- 5.8 Acct-Input-Packets ............................ 18
--
../data/rfc/rfc2866.txt-1. Introduction
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Managing dispersed serial line and modem pools for large numbers of
../data/rfc/rfc2866.txt- users can create the need for significant administrative support.
../data/rfc/rfc2866.txt- Since modem pools are by definition a link to the outside world, they
../data/rfc/rfc2866.txt: require careful attention to security, authorization and accounting.
../data/rfc/rfc2866.txt- This can be best achieved by managing a single "database" of users,
../data/rfc/rfc2866.txt- which allows for authentication (verifying user name and password) as
../data/rfc/rfc2866.txt- well as configuration information detailing the type of service to
../data/rfc/rfc2866.txt- deliver to the user (for example, SLIP, PPP, telnet, rlogin).
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- The RADIUS (Remote Authentication Dial In User Service) document [2]
../data/rfc/rfc2866.txt- specifies the RADIUS protocol used for Authentication and
../data/rfc/rfc2866.txt- Authorization. This memo extends the use of the RADIUS protocol to
../data/rfc/rfc2866.txt: cover delivery of accounting information from the Network Access
../data/rfc/rfc2866.txt: Server (NAS) to a RADIUS accounting server.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- This document obsoletes RFC 2139 [1]. A summary of the changes
../data/rfc/rfc2866.txt- between this document and RFC 2139 is available in the "Change Log"
../data/rfc/rfc2866.txt- appendix.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: Key features of RADIUS Accounting are:
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Client/Server Model
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- A Network Access Server (NAS) operates as a client of the
../data/rfc/rfc2866.txt: RADIUS accounting server. The client is responsible for
../data/rfc/rfc2866.txt: passing user accounting information to a designated RADIUS
../data/rfc/rfc2866.txt: accounting server.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Rigney Informational [Page 2]
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt:RFC 2866 RADIUS Accounting June 2000
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: The RADIUS accounting server is responsible for receiving the
../data/rfc/rfc2866.txt: accounting request and returning a response to the client
../data/rfc/rfc2866.txt- indicating that it has successfully received the request.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: The RADIUS accounting server can act as a proxy client to
../data/rfc/rfc2866.txt: other kinds of accounting servers.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Network Security
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: Transactions between the client and RADIUS accounting server
../data/rfc/rfc2866.txt- are authenticated through the use of a shared secret, which is
../data/rfc/rfc2866.txt- never sent over the network.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Extensible Protocol
../data/rfc/rfc2866.txt-
--
../data/rfc/rfc2866.txt- constitutes a session, with the beginning of the session
../data/rfc/rfc2866.txt- defined as the point where service is first provided and
../data/rfc/rfc2866.txt- the end of the session defined as the point where service
../data/rfc/rfc2866.txt- is ended. A user may have multiple sessions in parallel or
../data/rfc/rfc2866.txt- series if the NAS supports that, with each session
../data/rfc/rfc2866.txt: generating a separate start and stop accounting record with
../data/rfc/rfc2866.txt- its own Acct-Session-Id.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- silently discard
../data/rfc/rfc2866.txt- This means the implementation discards the packet without
../data/rfc/rfc2866.txt- further processing. The implementation SHOULD provide the
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Rigney Informational [Page 3]
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt:RFC 2866 RADIUS Accounting June 2000
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-2. Operation
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: When a client is configured to use RADIUS Accounting, at the start of
../data/rfc/rfc2866.txt: service delivery it will generate an Accounting Start packet
../data/rfc/rfc2866.txt- describing the type of service being delivered and the user it is
../data/rfc/rfc2866.txt: being delivered to, and will send that to the RADIUS Accounting
../data/rfc/rfc2866.txt- server, which will send back an acknowledgement that the packet has
../data/rfc/rfc2866.txt- been received. At the end of service delivery the client will
../data/rfc/rfc2866.txt: generate an Accounting Stop packet describing the type of service
../data/rfc/rfc2866.txt- that was delivered and optionally statistics such as elapsed time,
../data/rfc/rfc2866.txt- input and output octets, or input and output packets. It will send
../data/rfc/rfc2866.txt: that to the RADIUS Accounting server, which will send back an
../data/rfc/rfc2866.txt- acknowledgement that the packet has been received.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: The Accounting-Request (whether for Start or Stop) is submitted to
../data/rfc/rfc2866.txt: the RADIUS accounting server via the network. It is recommended that
../data/rfc/rfc2866.txt: the client continue attempting to send the Accounting-Request packet
../data/rfc/rfc2866.txt- until it receives an acknowledgement, using some form of backoff. If
../data/rfc/rfc2866.txt- no response is returned within a length of time, the request is re-
../data/rfc/rfc2866.txt- sent a number of times. The client can also forward requests to an
../data/rfc/rfc2866.txt- alternate server or servers in the event that the primary server is
../data/rfc/rfc2866.txt- down or unreachable. An alternate server can be used either after a
../data/rfc/rfc2866.txt- number of tries to the primary server fail, or in a round-robin
../data/rfc/rfc2866.txt- fashion. Retry and fallback algorithms are the topic of current
../data/rfc/rfc2866.txt- research and are not specified in detail in this document.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: The RADIUS accounting server MAY make requests of other servers in
../data/rfc/rfc2866.txt- order to satisfy the request, in which case it acts as a client.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: If the RADIUS accounting server is unable to successfully record the
../data/rfc/rfc2866.txt: accounting packet it MUST NOT send an Accounting-Response
../data/rfc/rfc2866.txt- acknowledgment to the client.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-2.1. Proxy
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- See the "RADIUS" RFC [2] for information on Proxy RADIUS. Proxy
../data/rfc/rfc2866.txt: Accounting RADIUS works the same way, as illustrated by the following
../data/rfc/rfc2866.txt- example.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: 1. The NAS sends an accounting-request to the forwarding server.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: 2. The forwarding server logs the accounting-request (if desired),
../data/rfc/rfc2866.txt- adds its Proxy-State (if desired) after any other Proxy-State
../data/rfc/rfc2866.txt- attributes, updates the Request Authenticator, and forwards the
../data/rfc/rfc2866.txt- request to the remote server.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Rigney Informational [Page 4]
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt:RFC 2866 RADIUS Accounting June 2000
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: 3. The remote server logs the accounting-request (if desired),
../data/rfc/rfc2866.txt- copies all Proxy-State attributes in order and unmodified from
../data/rfc/rfc2866.txt: the request to the response packet, and sends the accounting-
../data/rfc/rfc2866.txt- response to the forwarding server.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- 4. The forwarding server strips the last Proxy-State (if it added
../data/rfc/rfc2866.txt- one in step 2), updates the Response Authenticator and sends
../data/rfc/rfc2866.txt: the accounting-response to the NAS.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- A forwarding server MUST not modify existing Proxy-State or Class
../data/rfc/rfc2866.txt- attributes present in the packet.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- A forwarding server may either perform its forwarding function in a
--
../data/rfc/rfc2866.txt- takes responsibility for retransmissions so that its retransmission
../data/rfc/rfc2866.txt- policy is robust and scalable.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-3. Packet Format
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: Exactly one RADIUS Accounting packet is encapsulated in the UDP Data
../data/rfc/rfc2866.txt- field [4], where the UDP Destination Port field indicates 1813
../data/rfc/rfc2866.txt- (decimal).
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- When a reply is generated, the source and destination ports are
../data/rfc/rfc2866.txt- reversed.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: This memo documents the RADIUS Accounting protocol. The early
../data/rfc/rfc2866.txt: deployment of RADIUS Accounting was done using UDP port number 1646,
../data/rfc/rfc2866.txt- which conflicts with the "sa-msg-port" service. The officially
../data/rfc/rfc2866.txt: assigned port number for RADIUS Accounting is 1813.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- A summary of the RADIUS data format is shown below. The fields are
../data/rfc/rfc2866.txt- transmitted from left to right.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Rigney Informational [Page 5]
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt:RFC 2866 RADIUS Accounting June 2000
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- 0 1 2 3
../data/rfc/rfc2866.txt- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
../data/rfc/rfc2866.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- The Code field is one octet, and identifies the type of RADIUS
../data/rfc/rfc2866.txt- packet. When a packet is received with an invalid Code field, it
../data/rfc/rfc2866.txt- is silently discarded.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: RADIUS Accounting Codes (decimal) are assigned as follows:
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: 4 Accounting-Request
../data/rfc/rfc2866.txt: 5 Accounting-Response
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Identifier
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- The Identifier field is one octet, and aids in matching requests
../data/rfc/rfc2866.txt- and replies. The RADIUS server can detect a duplicate request if
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Authenticator
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- The Authenticator field is sixteen (16) octets. The most
../data/rfc/rfc2866.txt- significant octet is transmitted first. This value is used to
../data/rfc/rfc2866.txt: authenticate the messages between the client and RADIUS accounting
../data/rfc/rfc2866.txt- server.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Rigney Informational [Page 6]
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt:RFC 2866 RADIUS Accounting June 2000
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Request Authenticator
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: In Accounting-Request Packets, the Authenticator value is a 16
../data/rfc/rfc2866.txt- octet MD5 [5] checksum, called the Request Authenticator.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: The NAS and RADIUS accounting server share a secret. The Request
../data/rfc/rfc2866.txt: Authenticator field in Accounting-Request packets contains a one-
../data/rfc/rfc2866.txt- way MD5 hash calculated over a stream of octets consisting of the
../data/rfc/rfc2866.txt- Code + Identifier + Length + 16 zero octets + request attributes +
../data/rfc/rfc2866.txt- shared secret (where + indicates concatenation). The 16 octet MD5
../data/rfc/rfc2866.txt- hash value is stored in the Authenticator field of the
../data/rfc/rfc2866.txt: Accounting-Request packet.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: Note that the Request Authenticator of an Accounting-Request can
../data/rfc/rfc2866.txt- not be done the same way as the Request Authenticator of a RADIUS
../data/rfc/rfc2866.txt- Access-Request, because there is no User-Password attribute in an
../data/rfc/rfc2866.txt: Accounting-Request.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Response Authenticator
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: The Authenticator field in an Accounting-Response packet is called
../data/rfc/rfc2866.txt- the Response Authenticator, and contains a one-way MD5 hash
../data/rfc/rfc2866.txt: calculated over a stream of octets consisting of the Accounting-
../data/rfc/rfc2866.txt- Response Code, Identifier, Length, the Request Authenticator field
../data/rfc/rfc2866.txt: from the Accounting-Request packet being replied to, and the
../data/rfc/rfc2866.txt- response attributes if any, followed by the shared secret. The
../data/rfc/rfc2866.txt- resulting 16 octet MD5 hash value is stored in the Authenticator
../data/rfc/rfc2866.txt: field of the Accounting-Response packet.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Attributes
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Attributes may have multiple instances, in such a case the order
../data/rfc/rfc2866.txt- of attributes of the same type SHOULD be preserved. The order of
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Rigney Informational [Page 7]
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt:RFC 2866 RADIUS Accounting June 2000
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt:4.1. Accounting-Request
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Description
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: Accounting-Request packets are sent from a client (typically a
../data/rfc/rfc2866.txt: Network Access Server or its proxy) to a RADIUS accounting server,
../data/rfc/rfc2866.txt: and convey information used to provide accounting for a service
../data/rfc/rfc2866.txt- provided to a user. The client transmits a RADIUS packet with the
../data/rfc/rfc2866.txt: Code field set to 4 (Accounting-Request).
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: Upon receipt of an Accounting-Request, the server MUST transmit an
../data/rfc/rfc2866.txt: Accounting-Response reply if it successfully records the
../data/rfc/rfc2866.txt: accounting packet, and MUST NOT transmit any reply if it fails to
../data/rfc/rfc2866.txt: record the accounting packet.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Any attribute valid in a RADIUS Access-Request or Access-Accept
../data/rfc/rfc2866.txt: packet is valid in a RADIUS Accounting-Request packet, except that
../data/rfc/rfc2866.txt: the following attributes MUST NOT be present in an Accounting-
../data/rfc/rfc2866.txt- Request: User-Password, CHAP-Password, Reply-Message, State.
../data/rfc/rfc2866.txt- Either NAS-IP-Address or NAS-Identifier MUST be present in a
../data/rfc/rfc2866.txt: RADIUS Accounting-Request. It SHOULD contain a NAS-Port or NAS-
../data/rfc/rfc2866.txt- Port-Type attribute or both unless the service does not involve a
../data/rfc/rfc2866.txt- port or the NAS does not distinguish among its ports.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: If the Accounting-Request packet includes a Framed-IP-Address,
../data/rfc/rfc2866.txt- that attribute MUST contain the IP address of the user. If the
../data/rfc/rfc2866.txt- Access-Accept used the special values for Framed-IP-Address
../data/rfc/rfc2866.txt- telling the NAS to assign or negotiate an IP address for the user,
../data/rfc/rfc2866.txt: the Framed-IP-Address (if any) in the Accounting-Request MUST
../data/rfc/rfc2866.txt- contain the actual IP address assigned or negotiated.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: A summary of the Accounting-Request packet format is shown below.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- The fields are transmitted from left to right.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- 0 1 2 3
../data/rfc/rfc2866.txt- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Rigney Informational [Page 8]
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt:RFC 2866 RADIUS Accounting June 2000
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Code
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: 4 for Accounting-Request.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Identifier
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- The Identifier field MUST be changed whenever the content of the
../data/rfc/rfc2866.txt- Attributes field changes, and whenever a valid reply has been
../data/rfc/rfc2866.txt- received for a previous request. For retransmissions where the
../data/rfc/rfc2866.txt- contents are identical, the Identifier MUST remain unchanged.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Note that if Acct-Delay-Time is included in the attributes of an
../data/rfc/rfc2866.txt: Accounting-Request then the Acct-Delay-Time value will be updated
../data/rfc/rfc2866.txt- when the packet is retransmitted, changing the content of the
../data/rfc/rfc2866.txt- Attributes field and requiring a new Identifier and Request
../data/rfc/rfc2866.txt- Authenticator.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Request Authenticator
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: The Request Authenticator of an Accounting-Request contains a 16-octet
../data/rfc/rfc2866.txt- MD5 hash value calculated according to the method described in
../data/rfc/rfc2866.txt- "Request Authenticator" above.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Attributes
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- The Attributes field is variable in length, and contains a list of
../data/rfc/rfc2866.txt- Attributes.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt:4.2. Accounting-Response
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Description
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: Accounting-Response packets are sent by the RADIUS accounting
../data/rfc/rfc2866.txt: server to the client to acknowledge that the Accounting-Request
../data/rfc/rfc2866.txt: has been received and recorded successfully. If the Accounting-
../data/rfc/rfc2866.txt: Request was recorded successfully then the RADIUS accounting
../data/rfc/rfc2866.txt- server MUST transmit a packet with the Code field set to 5
../data/rfc/rfc2866.txt: (Accounting-Response). On reception of an Accounting-Response by
../data/rfc/rfc2866.txt- the client, the Identifier field is matched with a pending
../data/rfc/rfc2866.txt: Accounting-Request. The Response Authenticator field MUST contain
../data/rfc/rfc2866.txt: the correct response for the pending Accounting-Request. Invalid
../data/rfc/rfc2866.txt- packets are silently discarded.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: A RADIUS Accounting-Response is not required to have any
../data/rfc/rfc2866.txt- attributes in it.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: A summary of the Accounting-Response packet format is shown below.
../data/rfc/rfc2866.txt- The fields are transmitted from left to right.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Rigney Informational [Page 9]
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt:RFC 2866 RADIUS Accounting June 2000
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- 0 1 2 3
../data/rfc/rfc2866.txt- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
../data/rfc/rfc2866.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--
../data/rfc/rfc2866.txt- | Attributes ...
../data/rfc/rfc2866.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Code
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: 5 for Accounting-Response.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Identifier
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- The Identifier field is a copy of the Identifier field of the
../data/rfc/rfc2866.txt: Accounting-Request which caused this Accounting-Response.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Response Authenticator
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: The Response Authenticator of an Accounting-Response contains a
../data/rfc/rfc2866.txt- 16-octet MD5 hash value calculated according to the method
../data/rfc/rfc2866.txt- described in "Response Authenticator" above.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Attributes
../data/rfc/rfc2866.txt-
--
../data/rfc/rfc2866.txt- zero or more Attributes.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-5. Attributes
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- RADIUS Attributes carry the specific authentication, authorization
../data/rfc/rfc2866.txt: and accounting details for the request and response.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Some attributes MAY be included more than once. The effect of this
../data/rfc/rfc2866.txt- is attribute specific, and is specified in each attribute
../data/rfc/rfc2866.txt- description.
../data/rfc/rfc2866.txt-
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Rigney Informational [Page 10]
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt:RFC 2866 RADIUS Accounting June 2000
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- 0 1 2
../data/rfc/rfc2866.txt- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
../data/rfc/rfc2866.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Length
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- The Length field is one octet, and indicates the length of this
../data/rfc/rfc2866.txt- attribute including the Type, Length and Value fields. If an
../data/rfc/rfc2866.txt: attribute is received in an Accounting-Request with an invalid
../data/rfc/rfc2866.txt- Length, the entire request MUST be silently discarded.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Value
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- The Value field is zero or more octets and contains information
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Rigney Informational [Page 11]
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt:RFC 2866 RADIUS Accounting June 2000
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- [7] characters and String contains 8-bit binary data. Servers and
../data/rfc/rfc2866.txt- servers and clients MUST be able to deal with embedded nulls.
../data/rfc/rfc2866.txt- RADIUS implementers using C are cautioned not to use strcpy() when
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-5.1. Acct-Status-Type
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Description
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: This attribute indicates whether this Accounting-Request marks the
../data/rfc/rfc2866.txt- beginning of the user service (Start) or the end (Stop).
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: It MAY be used by the client to mark the start of accounting (for
../data/rfc/rfc2866.txt: example, upon booting) by specifying Accounting-On and to mark the
../data/rfc/rfc2866.txt: end of accounting (for example, just before a scheduled reboot) by
../data/rfc/rfc2866.txt: specifying Accounting-Off.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- A summary of the Acct-Status-Type attribute format is shown below.
../data/rfc/rfc2866.txt- The fields are transmitted from left to right.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- 0 1 2 3
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Rigney Informational [Page 12]
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt:RFC 2866 RADIUS Accounting June 2000
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Type
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- 40 for Acct-Status-Type.
--
../data/rfc/rfc2866.txt- The Value field is four octets.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- 1 Start
../data/rfc/rfc2866.txt- 2 Stop
../data/rfc/rfc2866.txt- 3 Interim-Update
../data/rfc/rfc2866.txt: 7 Accounting-On
../data/rfc/rfc2866.txt: 8 Accounting-Off
../data/rfc/rfc2866.txt: 9-14 Reserved for Tunnel Accounting
../data/rfc/rfc2866.txt- 15 Reserved for Failed
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-5.2. Acct-Delay-Time
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Description
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- This attribute indicates how many seconds the client has been
../data/rfc/rfc2866.txt- trying to send this record for, and can be subtracted from the
../data/rfc/rfc2866.txt- time of arrival on the server to find the approximate time of the
../data/rfc/rfc2866.txt: event generating this Accounting-Request. (Network transit time
../data/rfc/rfc2866.txt- is ignored.)
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Note that changing the Acct-Delay-Time causes the Identifier to
../data/rfc/rfc2866.txt- change; see the discussion under Identifier above.
../data/rfc/rfc2866.txt-
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Rigney Informational [Page 13]
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt:RFC 2866 RADIUS Accounting June 2000
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Type
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- 41 for Acct-Delay-Time.
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Description
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- This attribute indicates how many octets have been received from
../data/rfc/rfc2866.txt- the port over the course of this service being provided, and can
../data/rfc/rfc2866.txt: only be present in Accounting-Request records where the Acct-
../data/rfc/rfc2866.txt- Status-Type is set to Stop.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- A summary of the Acct-Input-Octets attribute format is shown below.
../data/rfc/rfc2866.txt- The fields are transmitted from left to right.
../data/rfc/rfc2866.txt-
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Rigney Informational [Page 14]
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt:RFC 2866 RADIUS Accounting June 2000
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-5.4. Acct-Output-Octets
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Description
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- This attribute indicates how many octets have been sent to the
../data/rfc/rfc2866.txt- port in the course of delivering this service, and can only be
../data/rfc/rfc2866.txt: present in Accounting-Request records where the Acct-Status-Type
../data/rfc/rfc2866.txt- is set to Stop.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- A summary of the Acct-Output-Octets attribute format is shown below.
../data/rfc/rfc2866.txt- The fields are transmitted from left to right.
../data/rfc/rfc2866.txt-
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-5.5. Acct-Session-Id
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Description
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: This attribute is a unique Accounting ID to make it easy to match
../data/rfc/rfc2866.txt- start and stop records in a log file. The start and stop records
../data/rfc/rfc2866.txt- for a given session MUST have the same Acct-Session-Id. An
../data/rfc/rfc2866.txt: Accounting-Request packet MUST have an Acct-Session-Id. An
../data/rfc/rfc2866.txt- Access-Request packet MAY have an Acct-Session-Id; if it does,
../data/rfc/rfc2866.txt: then the NAS MUST use the same Acct-Session-Id in the Accounting-
../data/rfc/rfc2866.txt- Request packets for that session.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- The Acct-Session-Id SHOULD contain UTF-8 encoded 10646 [7]
../data/rfc/rfc2866.txt- characters.
../data/rfc/rfc2866.txt-
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Rigney Informational [Page 15]
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt:RFC 2866 RADIUS Accounting June 2000
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- For example, one implementation uses a string with an 8-digit
../data/rfc/rfc2866.txt- upper case hexadecimal number, the first two digits increment on
../data/rfc/rfc2866.txt- each reboot (wrapping every 256 reboots) and the next 6 digits
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-5.6. Acct-Authentic
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Description
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: This attribute MAY be included in an Accounting-Request to
../data/rfc/rfc2866.txt- indicate how the user was authenticated, whether by RADIUS, the
../data/rfc/rfc2866.txt- NAS itself, or another remote authentication protocol. Users who
../data/rfc/rfc2866.txt- are delivered service without being authenticated SHOULD NOT
../data/rfc/rfc2866.txt: generate Accounting records.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- A summary of the Acct-Authentic attribute format is shown below. The
../data/rfc/rfc2866.txt- fields are transmitted from left to right.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- 0 1 2 3
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Rigney Informational [Page 16]
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt:RFC 2866 RADIUS Accounting June 2000
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Type
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- 45 for Acct-Authentic.
--
../data/rfc/rfc2866.txt-5.7. Acct-Session-Time
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Description
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- This attribute indicates how many seconds the user has received
../data/rfc/rfc2866.txt: service for, and can only be present in Accounting-Request records
../data/rfc/rfc2866.txt- where the Acct-Status-Type is set to Stop.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- A summary of the Acct-Session-Time attribute format is shown below.
../data/rfc/rfc2866.txt- The fields are transmitted from left to right.
../data/rfc/rfc2866.txt-
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Rigney Informational [Page 17]
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt:RFC 2866 RADIUS Accounting June 2000
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-5.8. Acct-Input-Packets
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Description
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- This attribute indicates how many packets have been received from
../data/rfc/rfc2866.txt- the port over the course of this service being provided to a
../data/rfc/rfc2866.txt: Framed User, and can only be present in Accounting-Request records
../data/rfc/rfc2866.txt- where the Acct-Status-Type is set to Stop.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- A summary of the Acct-Input-packets attribute format is shown below.
../data/rfc/rfc2866.txt- The fields are transmitted from left to right.
../data/rfc/rfc2866.txt-
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Description
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- This attribute indicates how many packets have been sent to the
../data/rfc/rfc2866.txt- port in the course of delivering this service to a Framed User,
../data/rfc/rfc2866.txt: and can only be present in Accounting-Request records where the
../data/rfc/rfc2866.txt- Acct-Status-Type is set to Stop.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- A summary of the Acct-Output-Packets attribute format is shown below.
../data/rfc/rfc2866.txt- The fields are transmitted from left to right.
../data/rfc/rfc2866.txt-
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Rigney Informational [Page 18]
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt:RFC 2866 RADIUS Accounting June 2000
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- 0 1 2 3
../data/rfc/rfc2866.txt- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
../data/rfc/rfc2866.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--
../data/rfc/rfc2866.txt-5.10. Acct-Terminate-Cause
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Description
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- This attribute indicates how the session was terminated, and can
../data/rfc/rfc2866.txt: only be present in Accounting-Request records where the Acct-
../data/rfc/rfc2866.txt- Status-Type is set to Stop.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- A summary of the Acct-Terminate-Cause attribute format is shown
../data/rfc/rfc2866.txt- below. The fields are transmitted from left to right.
../data/rfc/rfc2866.txt-
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Rigney Informational [Page 19]
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt:RFC 2866 RADIUS Accounting June 2000
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Type
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- 49 for Acct-Terminate-Cause
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Rigney Informational [Page 20]
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt:RFC 2866 RADIUS Accounting June 2000
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Admin Reboot Administrator is ending service on the NAS,
../data/rfc/rfc2866.txt- for example prior to rebooting the NAS.
../data/rfc/rfc2866.txt-
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-5.11. Acct-Multi-Session-Id
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Description
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: This attribute is a unique Accounting ID to make it easy to link
../data/rfc/rfc2866.txt- together multiple related sessions in a log file. Each session
../data/rfc/rfc2866.txt- linked together would have a unique Acct-Session-Id but the same
../data/rfc/rfc2866.txt- Acct-Multi-Session-Id. It is strongly recommended that the Acct-
../data/rfc/rfc2866.txt- Multi-Session-Id contain UTF-8 encoded 10646 [7] characters.
../data/rfc/rfc2866.txt-
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Rigney Informational [Page 21]
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt:RFC 2866 RADIUS Accounting June 2000
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- 0 1 2
../data/rfc/rfc2866.txt- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
../data/rfc/rfc2866.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--
../data/rfc/rfc2866.txt-5.12. Acct-Link-Count
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Description
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- This attribute gives the count of links which are known to have been
../data/rfc/rfc2866.txt: in a given multilink session at the time the accounting record is
../data/rfc/rfc2866.txt- generated. The NAS MAY include the Acct-Link-Count attribute in any
../data/rfc/rfc2866.txt: Accounting-Request which might have multiple links.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- A summary of the Acct-Link-Count attribute format is show below. The
../data/rfc/rfc2866.txt- fields are transmitted from left to right.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- 0 1 2 3
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Rigney Informational [Page 22]
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt:RFC 2866 RADIUS Accounting June 2000
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Type
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- 51 for Acct-Link-Count.
--
../data/rfc/rfc2866.txt- Value
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- The Value field is four octets, and contains the number of links
../data/rfc/rfc2866.txt- seen so far in this Multilink Session.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: It may be used to make it easier for an accounting server to know
../data/rfc/rfc2866.txt- when it has all the records for a given Multilink session. When
../data/rfc/rfc2866.txt: the number of Accounting-Requests received with Acct-Status-Type =
../data/rfc/rfc2866.txt- Stop and the same Acct-Multi-Session-Id and unique Acct-Session-
../data/rfc/rfc2866.txt- Id's equals the largest value of Acct-Link-Count seen in those
../data/rfc/rfc2866.txt: Accounting-Requests, all Stop Accounting-Requests for that
../data/rfc/rfc2866.txt- Multilink Session have been received.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: An example showing 8 Accounting-Requests should make things
../data/rfc/rfc2866.txt- clearer. For clarity only the relevant attributes are shown, but
../data/rfc/rfc2866.txt: additional attributes containing accounting information will also
../data/rfc/rfc2866.txt: be present in the Accounting-Request.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Multi-Session-Id Session-Id Status-Type Link-Count
../data/rfc/rfc2866.txt- "10" "10" Start 1
../data/rfc/rfc2866.txt- "10" "11" Start 2
../data/rfc/rfc2866.txt- "10" "11" Stop 2
--
../data/rfc/rfc2866.txt- "10" "10" Stop 4
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-5.13. Table of Attributes
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- The following table provides a guide to which attributes may be found
../data/rfc/rfc2866.txt: in Accounting-Request packets. No attributes should be found in
../data/rfc/rfc2866.txt: Accounting-Response packets except Proxy-State and possibly Vendor-
../data/rfc/rfc2866.txt- Specific.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- # Attribute
../data/rfc/rfc2866.txt- 0-1 User-Name
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Rigney Informational [Page 23]
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt:RFC 2866 RADIUS Accounting June 2000
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- 0-1 NAS-IP-Address [Note 1]
../data/rfc/rfc2866.txt- 0-1 NAS-Port
../data/rfc/rfc2866.txt- 0-1 Service-Type
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Rigney Informational [Page 24]
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt:RFC 2866 RADIUS Accounting June 2000
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- 0-1 NAS-Port-Type
../data/rfc/rfc2866.txt- 0-1 Port-Limit
../data/rfc/rfc2866.txt- 0-1 Login-LAT-Port
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: [Note 1] An Accounting-Request MUST contain either a NAS-IP-Address
../data/rfc/rfc2866.txt- or a NAS-Identifier (or both).
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- The following table defines the above table entries.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- 0 This attribute MUST NOT be present
--
../data/rfc/rfc2866.txt- 26 [8].
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-7. Security Considerations
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Security issues are discussed in sections concerning the
../data/rfc/rfc2866.txt: authenticator included in accounting requests and responses, using a
../data/rfc/rfc2866.txt- shared secret which is never sent over the network.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-8. Change Log
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- US-ASCII replaced by UTF-8.
--
../data/rfc/rfc2866.txt- Added notes on Proxy.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Framed-IP-Address should contain the actual IP address of the user.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- If Acct-Session-ID was sent in an access-request, it must be used in
../data/rfc/rfc2866.txt: the accounting-request for that session.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- New values added to Acct-Status-Type.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Added an IANA Considerations section.
../data/rfc/rfc2866.txt-
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Rigney Informational [Page 25]
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt:RFC 2866 RADIUS Accounting June 2000
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-9. References
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: [1] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- [2] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
../data/rfc/rfc2866.txt- Authentication Dial In User Service (RADIUS)", RFC 2865, June
../data/rfc/rfc2866.txt- 2000.
../data/rfc/rfc2866.txt-
--
../data/rfc/rfc2866.txt- [8] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
../data/rfc/rfc2866.txt- Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-10. Acknowledgements
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt: RADIUS and RADIUS Accounting were originally developed by Steve
../data/rfc/rfc2866.txt- Willens of Livingston Enterprises for their PortMaster series of
../data/rfc/rfc2866.txt- Network Access Servers.
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-11. Chair's Address
../data/rfc/rfc2866.txt-
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Rigney Informational [Page 26]
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt:RFC 2866 RADIUS Accounting June 2000
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-12. Author's Address
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Questions about this memo can also be directed to:
--
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-Rigney Informational [Page 27]
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt:RFC 2866 RADIUS Accounting June 2000
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt-13. Full Copyright Statement
../data/rfc/rfc2866.txt-
../data/rfc/rfc2866.txt- Copyright (C) The Internet Society (2000). All Rights Reserved.
--
../data/rfc/rfc6183.txt- algorithm, and observation information) into appropriate fields in
../data/rfc/rfc6183.txt- the existing Data Records or into Data Records defined by new
../data/rfc/rfc6183.txt- Options Templates.
../data/rfc/rfc6183.txt-
../data/rfc/rfc6183.txt- IPFIX transport protocol conversion can be used to enhance the export
../data/rfc/rfc6183.txt: reliability, for example, for data retention and accounting. In this
../data/rfc/rfc6183.txt- case, the Intermediate Conversion Process covers the following
../data/rfc/rfc6183.txt- functions:
../data/rfc/rfc6183.txt-
../data/rfc/rfc6183.txt- o Relaying Data Records, (Options) Template Records, and Data
../data/rfc/rfc6183.txt- Records defined by Options Templates.
--
../data/rfc/rfc7966.txt- The following terms are also used in this document:
../data/rfc/rfc7966.txt-
../data/rfc/rfc7966.txt- AAA broker
../data/rfc/rfc7966.txt-
../data/rfc/rfc7966.txt- An entity that manages Authentication, Authorization, and
../data/rfc/rfc7966.txt: Accounting (AAA) traffic between roaming partner networks.
../data/rfc/rfc7966.txt-
../data/rfc/rfc7966.txt- AAA broker network
../data/rfc/rfc7966.txt-
../data/rfc/rfc7966.txt- A network operated by a AAA broker, which consists of necessary
../data/rfc/rfc7966.txt- AAA functions to provide AAA brokering services for its customer
--
../data/rfc/rfc1175.txt- attributes on the quality and appropriateness of communication.
../data/rfc/rfc1175.txt- Hard copies may be obtained, for a fee, from: Publications
../data/rfc/rfc1175.txt- Distribution Services, The RAND Corporation, P.O. Box 2138, Santa
../data/rfc/rfc1175.txt- Monica, CA 90406-2138.
../data/rfc/rfc1175.txt-
../data/rfc/rfc1175.txt: U.S. General Accounting Office, Computer Security - Virus Highlights
../data/rfc/rfc1175.txt- Need for Improved Internet Management, 36 pgs., United States General
../data/rfc/rfc1175.txt: Accounting Office, Washington, DC, 1989.
../data/rfc/rfc1175.txt-
../data/rfc/rfc1175.txt: This report (GAO/IMTEC-89-57), by the U.S. Government Accounting
../data/rfc/rfc1175.txt- Office, describes the worm and its effects. It gives a good
../data/rfc/rfc1175.txt- overview of the various U.S. agencies involved in the Internet
../data/rfc/rfc1175.txt- today and their concerns vis-a-vis computer security and
../data/rfc/rfc1175.txt- networking. Available on-line on host nnsc.nsf.net, directory
../data/rfc/rfc1175.txt- pub, filename GAO_RPT; and on nis.nsf.net, directory nsfnet,
--
../data/rfc/rfc3917.txt- 2.3. Metering Process . . . . . . . . . . . . . . . . . . . 4
../data/rfc/rfc3917.txt- 2.4. Flow Record. . . . . . . . . . . . . . . . . . . . . . 5
../data/rfc/rfc3917.txt- 2.5. Exporting Process. . . . . . . . . . . . . . . . . . . 5
../data/rfc/rfc3917.txt- 2.6. Collecting Process . . . . . . . . . . . . . . . . . . 5
../data/rfc/rfc3917.txt- 3. Applications Requiring IP Flow Information Export . . . . . . 6
../data/rfc/rfc3917.txt: 3.1. Usage-based Accounting . . . . . . . . . . . . . . . . 6
../data/rfc/rfc3917.txt- 3.2. Traffic Profiling. . . . . . . . . . . . . . . . . . . 7
../data/rfc/rfc3917.txt- 3.3. Traffic Engineering. . . . . . . . . . . . . . . . . . 7
../data/rfc/rfc3917.txt- 3.4. Attack/Intrusion Detection . . . . . . . . . . . . . . 7
../data/rfc/rfc3917.txt- 3.5. QoS Monitoring . . . . . . . . . . . . . . . . . . . . 8
../data/rfc/rfc3917.txt- 4. Distinguishing Flows. . . . . . . . . . . . . . . . . . . . . 8
--
../data/rfc/rfc3917.txt- significance (required (must), recommended (should), optional (may))
../data/rfc/rfc3917.txt- could differ for specific implementations and/or for specific
../data/rfc/rfc3917.txt- application scenarios. Therefore we derive the requirements from the
../data/rfc/rfc3917.txt- general functionality of the selected applications. Some particular
../data/rfc/rfc3917.txt- cases will even mandate more stringent requirements than the ones
../data/rfc/rfc3917.txt: defined in this document. For example, usage-based accounting is
../data/rfc/rfc3917.txt- certainly the application that will probably mandate the highest
../data/rfc/rfc3917.txt- degree of reliability amongst the applications discussed below. The
../data/rfc/rfc3917.txt- reliability requirements defined in sections 5.1 and 6.3.2. are not
../data/rfc/rfc3917.txt- sufficient to guarantee the level of reliability that is needed for
../data/rfc/rfc3917.txt: many usage-based accounting systems. Particular reliability
../data/rfc/rfc3917.txt: requirements for accounting systems are discussed in [RFC2975].
../data/rfc/rfc3917.txt-
../data/rfc/rfc3917.txt:3.1. Usage-based Accounting
../data/rfc/rfc3917.txt-
../data/rfc/rfc3917.txt- Several new business models for selling IP services and IP-based
../data/rfc/rfc3917.txt- services are currently under investigation. Beyond flat rate
../data/rfc/rfc3917.txt: services which do not need accounting, accounting can be based on
../data/rfc/rfc3917.txt: time or volume. Accounting data can serve as input for billing
../data/rfc/rfc3917.txt: systems. Accounting can be performed per user or per user group, it
../data/rfc/rfc3917.txt- can be performed just for basic IP service or individually per high-
../data/rfc/rfc3917.txt- level service and/or per content type delivered. For advanced/future
../data/rfc/rfc3917.txt: services, accounting may also be performed per class of service, per
../data/rfc/rfc3917.txt- application, per time of day, per (label switched) path used, etc.
../data/rfc/rfc3917.txt-
../data/rfc/rfc3917.txt-
../data/rfc/rfc3917.txt-
../data/rfc/rfc3917.txt-
--
../data/rfc/rfc3917.txt- that anonymization is not originally an application requirement, but
../data/rfc/rfc3917.txt- derived from general requirements for treatment of measured traffic
../data/rfc/rfc3917.txt- data within a network.
../data/rfc/rfc3917.txt-
../data/rfc/rfc3917.txt- For several applications anonymization cannot be applied, for example
../data/rfc/rfc3917.txt: for accounting and traffic engineering. However, for protecting the
../data/rfc/rfc3917.txt- network user's privacy, anonymization should be applied whenever
../data/rfc/rfc3917.txt-
../data/rfc/rfc3917.txt-
../data/rfc/rfc3917.txt-
../data/rfc/rfc3917.txt-Quittek, et al. Informational [Page 18]
--
../data/rfc/rfc3917.txt- public Internet. Therefore it cannot be excluded that an attacker
../data/rfc/rfc3917.txt- captures or modifies packets or inserts additional packets.
../data/rfc/rfc3917.txt-
../data/rfc/rfc3917.txt- This section describes security requirements for IPFIX. Like other
../data/rfc/rfc3917.txt- requirements, the security requirements differ among the considered
../data/rfc/rfc3917.txt: applications. The incentive to modify collected data for accounting
../data/rfc/rfc3917.txt- or intrusion detection for instance is usually higher than the
../data/rfc/rfc3917.txt- incentive to change data collected for traffic profiling. A detailed
../data/rfc/rfc3917.txt- list of the required security features per application can be found
../data/rfc/rfc3917.txt- in the appendix.
../data/rfc/rfc3917.txt-
--
../data/rfc/rfc3917.txt- extensibility of the IPFIX protocol are sufficient to support
../data/rfc/rfc3917.txt- anonymized flow records when appropriate methods are standardized.
../data/rfc/rfc3917.txt-
../data/rfc/rfc3917.txt-10.2. Forgery of Flow Records
../data/rfc/rfc3917.txt-
../data/rfc/rfc3917.txt: If flow records are used in accounting and/or security applications,
../data/rfc/rfc3917.txt- there are potentially strong incentives to forge exported IPFIX flow
../data/rfc/rfc3917.txt- records (for example, to save money or prevent the detection of an
../data/rfc/rfc3917.txt- attack). This can be done either by altering flow records on the
../data/rfc/rfc3917.txt- path or by injecting forged flow records that pretend to be
../data/rfc/rfc3917.txt- originated by the original exporting process.
--
../data/rfc/rfc3917.txt-----------------------------------------------------. | | |
../data/rfc/rfc3917.txt-C: Traffic Engineering | | | |
../data/rfc/rfc3917.txt-----------------------------------------------. | | | |
../data/rfc/rfc3917.txt-B: Traffic Profiling | | | | |
../data/rfc/rfc3917.txt-----------------------------------------. | | | | |
../data/rfc/rfc3917.txt:A: Usage-based Accounting | | | | | |
../data/rfc/rfc3917.txt-----------------------------------. | | | | | |
../data/rfc/rfc3917.txt- | | | | | | |
../data/rfc/rfc3917.txt-| Sect. | Requirement | A | B | C | D | E | IPFIX|
../data/rfc/rfc3917.txt-|-------+-------------------------+-----+-----+-----+-----+-----+------|
../data/rfc/rfc3917.txt-| 4. | DISTINGUISHING FLOWS |
--
../data/rfc/rfc3917.txt- (e) If sampling is supported, sampling configuration changes must
../data/rfc/rfc3917.txt- be indicated to all collecting processes.
../data/rfc/rfc3917.txt- (f) If overload behavior is supported and it induces changes in
../data/rfc/rfc3917.txt- the metering process behavior, the overload behavior must be
../data/rfc/rfc3917.txt- clearly defined.
../data/rfc/rfc3917.txt: (g) Precise time-based accounting requires reaction to a flow
../data/rfc/rfc3917.txt- timeout.
../data/rfc/rfc3917.txt- (h) If a packet is fragmented, each fragment is counted as an
../data/rfc/rfc3917.txt- individual packet.
../data/rfc/rfc3917.txt- (i) If protocol type is ICMP.
../data/rfc/rfc3917.txt-
--
../data/rfc/rfc3917.txt- [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
../data/rfc/rfc3917.txt- Jacobson, "RTP: A Transport Protocol for Real-Time
../data/rfc/rfc3917.txt- Applications", STD 64, RFC 3550, July 2003.
../data/rfc/rfc3917.txt-
../data/rfc/rfc3917.txt- [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to
../data/rfc/rfc3917.txt: Accounting Management", RFC 2975, October 2000.
../data/rfc/rfc3917.txt-
../data/rfc/rfc3917.txt- [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
../data/rfc/rfc3917.txt- McManus, "Requirements for Traffic Engineering Over
../data/rfc/rfc3917.txt- MPLS", RFC 2702, September 1999.
../data/rfc/rfc3917.txt-
--
../data/rfc/rfc2724.txt-
../data/rfc/rfc2724.txt- [GUAR-QOS] Shenker, S., Partridge, C. and R. Guerin, "Specification
../data/rfc/rfc2724.txt- of Guaranteed Quality of Service", RFC 2212, September
../data/rfc/rfc2724.txt- 1997.
../data/rfc/rfc2724.txt-
../data/rfc/rfc2724.txt: [IIS-ACCT] Maiocchi, S: "NeTraMet & NeMaC for IIS Accounting:
../data/rfc/rfc2724.txt- Users' Guide", CEFRIEL, Milan, 5 May 1998. (See also
../data/rfc/rfc2724.txt- http://www.cefriel.it/ntw)
../data/rfc/rfc2724.txt-
../data/rfc/rfc2724.txt- [IIS-RSVP] Wroclawski, J., "The Use of RSVP with IETF Integrated
../data/rfc/rfc2724.txt- Services", RFC 2210, September 1997.
--
../data/rfc/rfc6097.txt- be discussed in this document. The approaches discussed do not
../data/rfc/rfc6097.txt- include all possible discovery mechanisms, but are limited to those
../data/rfc/rfc6097.txt- considered to fit most simply into the PMIPv6 environment.
../data/rfc/rfc6097.txt-
../data/rfc/rfc6097.txt- o LMA Address is retrieved from the Authentication, Authorization,
../data/rfc/rfc6097.txt: and Accounting (AAA) infrastructure during the network access
../data/rfc/rfc6097.txt- authentication procedure when the MN attaches to the MAG.
../data/rfc/rfc6097.txt-
../data/rfc/rfc6097.txt- o LMA Fully Qualified Domain Name (FQDN) is retrieved from the AAA
../data/rfc/rfc6097.txt- infrastructure during the network access authentication, followed
../data/rfc/rfc6097.txt- by a Domain Name System (DNS) lookup.
--
../data/rfc/rfc1649.txt-
../data/rfc/rfc1649.txt- The RELAY-MTA and Domain documents are coordinated by the group
../data/rfc/rfc1649.txt- specified in the Community document. The procedures for document
../data/rfc/rfc1649.txt- information gathering and distribution, are for further study.
../data/rfc/rfc1649.txt-
../data/rfc/rfc1649.txt:3.5. Minimum Statistics/Accounting
../data/rfc/rfc1649.txt-
../data/rfc/rfc1649.txt- The following are not required for all MTAs. The information is
../data/rfc/rfc1649.txt- provided as guidelines for MTA managers. This is helpful for
../data/rfc/rfc1649.txt- observing service use and evaluating service performance.
../data/rfc/rfc1649.txt-
--
../data/rfc/rfc7424.txt-4.3.4. Inline Data Path Measurement
../data/rfc/rfc7424.txt-
../data/rfc/rfc7424.txt- Implementations may perform recognition of large flows by performing
../data/rfc/rfc7424.txt- measurements on traffic in the data path of a router. Such an
../data/rfc/rfc7424.txt- approach would be expected to operate at the interface speed on every
../data/rfc/rfc7424.txt: interface, accounting for all packets processed by the data path of
../data/rfc/rfc7424.txt- the router. An example of such an approach is described in IPFIX
../data/rfc/rfc7424.txt- [RFC5470].
../data/rfc/rfc7424.txt-
../data/rfc/rfc7424.txt- Using inline data path measurement, a faster and more accurate
../data/rfc/rfc7424.txt- indication of large flows mapped to each of the component links in a
--
../data/rfc/rfc7424.txt- Curtis, R., and S. Banerjee, "DevoFlow: Cost-Effective
../data/rfc/rfc7424.txt- Flow Management for High Performance Enterprise
../data/rfc/rfc7424.txt- Networks", Proceedings of the ACM SIGCOMM, 2010.
../data/rfc/rfc7424.txt-
../data/rfc/rfc7424.txt- [FLOW-ACC] Zseby, T., Hirsch, T., and B. Claise, "Packet Sampling
../data/rfc/rfc7424.txt: for Flow Accounting: Challenges and Limitations",
../data/rfc/rfc7424.txt- Proceedings of the 9th international Passive and Active
../data/rfc/rfc7424.txt- Measurement Conference, 2008.
../data/rfc/rfc7424.txt-
../data/rfc/rfc7424.txt- [ITCOM] Jo, J., Kim, Y., Chao, H., and F. Merat, "Internet
../data/rfc/rfc7424.txt- traffic load balancing using dynamic hashing with flow
../data/rfc/rfc7424.txt- volume", SPIE ITCOM, 2002.
../data/rfc/rfc7424.txt-
../data/rfc/rfc7424.txt- [NDTM] Estan, C. and G. Varghese, "New Directions in Traffic
../data/rfc/rfc7424.txt: Measurement and Accounting", Proceedings of ACM SIGCOMM,
../data/rfc/rfc7424.txt- August 2002.
../data/rfc/rfc7424.txt-
../data/rfc/rfc7424.txt- [NVGRE] Garg, P. and Y. Wang, "NVGRE: Network Virtualization
../data/rfc/rfc7424.txt- using Generic Routing Encapsulation", Work in Progress,
../data/rfc/rfc7424.txt- draft-sridharan-virtualization-nvgre-07, November 2014.
--
../data/rfc/rfc4682.txt- (decoded) back to analog output by a compatible CODEC at the
../data/rfc/rfc4682.txt- receiving end.
../data/rfc/rfc4682.txt-
../data/rfc/rfc4682.txt- Operations Systems Support
../data/rfc/rfc4682.txt- An Operations Systems Support system (OSS) is a system of back office
../data/rfc/rfc4682.txt: software components used for fault, configuration, accounting,
../data/rfc/rfc4682.txt- performance, and security management working in interaction with each
../data/rfc/rfc4682.txt- other and providing the operations support in deployed PacketCable
../data/rfc/rfc4682.txt- systems.
../data/rfc/rfc4682.txt-
../data/rfc/rfc4682.txt- Key Distribution Center
--
../data/rfc/rfc6697.txt-
../data/rfc/rfc6697.txt- o where the peer's home EAP server also performs re-authentication;
../data/rfc/rfc6697.txt- and
../data/rfc/rfc6697.txt-
../data/rfc/rfc6697.txt- o where a local re-authentication server exists but is co-located
../data/rfc/rfc6697.txt: with an Authentication, Authorization, and Accounting (AAA) proxy
../data/rfc/rfc6697.txt- within the domain.
../data/rfc/rfc6697.txt-
../data/rfc/rfc6697.txt- Other work provides further pieces of the solution or insight into
../data/rfc/rfc6697.txt- the problem. For the purpose of this memo, Hoeper, et al. [RFC5749]
../data/rfc/rfc6697.txt- provide an abstract mechanism for distribution of keying material
--
../data/rfc/rfc6697.txt- moves from one authenticator to another, the peer may be
../data/rfc/rfc6697.txt- authenticated by the different authenticator during a period of time,
../data/rfc/rfc6697.txt- and the authenticator to which the peer is currently attached needs
../data/rfc/rfc6697.txt- to create a new AAA user session; however, the AAA server should not
../data/rfc/rfc6697.txt- view these handoffs as different sessions. Otherwise, this may
../data/rfc/rfc6697.txt: affect user experience and also cause accounting or logging issues.
../data/rfc/rfc6697.txt- For example, session ID creation, in most cases, is done by each
../data/rfc/rfc6697.txt- authenticator to which the peer attaches. In this sense, the new
../data/rfc/rfc6697.txt- authenticator acting as AAA client needs to create a new AAA user
../data/rfc/rfc6697.txt- session from scratch, which forces its corresponding AAA server to
../data/rfc/rfc6697.txt- terminate the existing user session with the previous authenticator
--
../data/rfc/rfc1356.txt- Use of the single network layer protocol circuits described in
../data/rfc/rfc1356.txt- section 3.2 is more efficient in terms of bandwidth if only a
../data/rfc/rfc1356.txt- limited number of protocols are supported by a system. It also
../data/rfc/rfc1356.txt- allows each system to determine exactly which protocols are
../data/rfc/rfc1356.txt- supported by its communicating partner. Other advantages include
../data/rfc/rfc1356.txt: being able to use X.25 accounting to detail each protocol and
../data/rfc/rfc1356.txt- different quality of service or flow control windows for different
../data/rfc/rfc1356.txt- protocols.
../data/rfc/rfc1356.txt-
../data/rfc/rfc1356.txt- The Null encapsulation, for multiplexing, is useful when a system,
../data/rfc/rfc1356.txt- for any reason (such as implementation restrictions or network cost
--
../data/rfc/rfc4923.txt- elastic application has no such boundary. Another way to look at the
../data/rfc/rfc4923.txt- difference is that real-time applications have an irreducible lower
../data/rfc/rfc4923.txt- bound on their bandwidth requirements. For example, the typical
../data/rfc/rfc4923.txt- G.711 payload is delivered in 160-byte samples (plus 40 bytes of IP/
../data/rfc/rfc4923.txt- UDP/RTP headers) at 20 millisecond intervals. This will yield 80
../data/rfc/rfc4923.txt: kbps of bandwidth, without silence suppression, and not accounting
../data/rfc/rfc4923.txt- for the layer 2 overhead. To operate in real-time, a G.711 codec
../data/rfc/rfc4923.txt- requires the network over which its data will be delivered to support
../data/rfc/rfc4923.txt- communications at 80 kbps at the IP layer with roughly constant end-
../data/rfc/rfc4923.txt- to-end delay and nominal or no loss. If this is not possible (if
../data/rfc/rfc4923.txt- there is significant loss or wide variations in delay), voice quality
--
../data/rfc/rfc5846.txt- with the Global (G) bit set and the Revocation Trigger field set to
../data/rfc/rfc5846.txt- "Per-Peer Policy" impacts all mobility sessions that are registered
../data/rfc/rfc5846.txt- with the mobile access gateway and its local mobility anchor peer,
../data/rfc/rfc5846.txt- the local mobility anchor MUST be locally configurable to authorize
../data/rfc/rfc5846.txt- such specific functionality. Additional mechanisms, such as a policy
../data/rfc/rfc5846.txt: store or Authentication, Authorization, and Accounting (AAA) may be
../data/rfc/rfc5846.txt- employed, but these are outside the scope of this specification.
../data/rfc/rfc5846.txt-
../data/rfc/rfc5846.txt-14. Acknowledgements
../data/rfc/rfc5846.txt-
../data/rfc/rfc5846.txt- The authors would like to thank Ryuji Wakikawa, Bruno Mongazon-
--
../data/rfc/rfc2607.txt- The Network Access Server (NAS) is the device that clients contact
../data/rfc/rfc2607.txt- in order to get access to the network.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- RADIUS server
../data/rfc/rfc2607.txt- This is a server which provides for authentication/authorization
../data/rfc/rfc2607.txt: via the protocol described in [3], and for accounting as described
../data/rfc/rfc2607.txt- in [4].
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-
--
../data/rfc/rfc2607.txt-RFC 2607 Proxy Chaining and Policy in Roaming June 1999
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- RADIUS proxy
../data/rfc/rfc2607.txt- In order to provide for the routing of RADIUS authentication and
../data/rfc/rfc2607.txt: accounting requests, a RADIUS proxy can be employed. To the NAS,
../data/rfc/rfc2607.txt- the RADIUS proxy appears to act as a RADIUS server, and to the
../data/rfc/rfc2607.txt- RADIUS server, the proxy appears to act as a RADIUS client.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- Network Access Identifier
../data/rfc/rfc2607.txt- In order to provide for the routing of RADIUS authentication and
../data/rfc/rfc2607.txt: accounting requests, the userID field used in PPP (known as the
../data/rfc/rfc2607.txt- Network Access Identifier or NAI) and in the subsequent RADIUS
../data/rfc/rfc2607.txt: authentication and accounting requests, can contain structure.
../data/rfc/rfc2607.txt- This structure provides a means by which the RADIUS proxy will
../data/rfc/rfc2607.txt- locate the RADIUS server that is to receive the request. The NAI
../data/rfc/rfc2607.txt- is defined in [6].
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- Roaming relationships
--
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-4. Introduction
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- Today, as described in [1], proxy chaining is widely deployed for the
../data/rfc/rfc2607.txt- purposes of providing roaming services. In such systems,
../data/rfc/rfc2607.txt: authentication/authorization and accounting packets are routed
../data/rfc/rfc2607.txt- between a NAS device and a home server through a series of proxies.
../data/rfc/rfc2607.txt- Consultation of the home server is required for password-based
../data/rfc/rfc2607.txt- authentication, since the home server maintains the password database
../data/rfc/rfc2607.txt- and thus it is necessary for the NAS to communicate with the home
../data/rfc/rfc2607.txt- authentication server in order to verify the user's identity.
--
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- Scalability improvement
../data/rfc/rfc2607.txt- Authentication forwarding
../data/rfc/rfc2607.txt- Capabilities adjustment
../data/rfc/rfc2607.txt- Policy implementation
../data/rfc/rfc2607.txt: Accounting reliability improvement
../data/rfc/rfc2607.txt- Atomic operation
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- Scalability improvement
../data/rfc/rfc2607.txt- In large scale roaming systems, it is necessary to provide for
../data/rfc/rfc2607.txt- scalable management of keys used for integrity protection and
--
../data/rfc/rfc2607.txt- one for each partner pair. However, were the partners to
../data/rfc/rfc2607.txt- route authentication requests through a central proxy, only
../data/rfc/rfc2607.txt- 100 shared secrets would be needed, one for each partner. The
../data/rfc/rfc2607.txt- reduction in the number of partner pairs also brings with it
../data/rfc/rfc2607.txt- other benefits, such as a reduction in the number of bilateral
../data/rfc/rfc2607.txt: agreements and accounting and auditing overhead. Thus,
../data/rfc/rfc2607.txt- hierarchical routing might be desirable even if an
../data/rfc/rfc2607.txt- authentiation protocol supporting automated key exchange were
../data/rfc/rfc2607.txt- available.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- Capabilities adjustment
--
../data/rfc/rfc2607.txt- probably not be necessary.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- Authentication forwarding
../data/rfc/rfc2607.txt- Since roaming associations frequently implement hierarchical
../data/rfc/rfc2607.txt- forwarding in order to improve scalability, in order for a NAS
../data/rfc/rfc2607.txt: and home server to communicate, authentication and accounting
../data/rfc/rfc2607.txt- packets are forwarded by one or more proxies. The path
../data/rfc/rfc2607.txt- travelled by these packets, known as the roaming relationship
../data/rfc/rfc2607.txt- path, is determined from the Network Access Identifier (NAI),
../data/rfc/rfc2607.txt- described in [6]. Since most NAS devices do not implement
../data/rfc/rfc2607.txt- forwarding logic, a proxy is needed to enable forwarding of
../data/rfc/rfc2607.txt: authentication and accounting packets. For reasons that are
../data/rfc/rfc2607.txt- described in the security section, in proxy systems it is
../data/rfc/rfc2607.txt: desirable for accounting and authentication packets to follow
../data/rfc/rfc2607.txt- the same path.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- Note: The way a proxy learns the mapping between NAI and the
../data/rfc/rfc2607.txt- home server is beyond the scope of this document. This
../data/rfc/rfc2607.txt- mapping can be accomplished by static configuration in the
--
../data/rfc/rfc2607.txt-RFC 2607 Proxy Chaining and Policy in Roaming June 1999
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- operates as a "man in the middle."
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt: Accounting reliability improvement
../data/rfc/rfc2607.txt- In roaming systems based on proxy chaining, it is necessary
../data/rfc/rfc2607.txt: for accounting information to be forwarded between the NAS and
../data/rfc/rfc2607.txt- the home server. Thus roaming is inherently an interdomain
../data/rfc/rfc2607.txt- application.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt: This represents a problem since the RADIUS accounting
../data/rfc/rfc2607.txt- protocol, described in [4] is not designed for use on an
../data/rfc/rfc2607.txt: Internet scale. Given that in roaming accounting packets
../data/rfc/rfc2607.txt- travel between administrative domains, packets will often pass
../data/rfc/rfc2607.txt- through network access points (NAPs) where packet loss may be
../data/rfc/rfc2607.txt- substantial. This can result in unacceptable rates of
../data/rfc/rfc2607.txt: accounting data loss.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- For example, in a proxy chaining system involving four
../data/rfc/rfc2607.txt- systems, a one percent failure rate on each hop can result in
../data/rfc/rfc2607.txt: loss of 3.9 percent of all accounting transactions. Placement
../data/rfc/rfc2607.txt: of an accounting proxy near the NAS may improve reliability by
../data/rfc/rfc2607.txt: enabling enabling persistent storage of accounting records and
../data/rfc/rfc2607.txt- long duration retry.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- Atomic operation
../data/rfc/rfc2607.txt- In order to ensure consistency among all parties required to
../data/rfc/rfc2607.txt: process accounting data, it can be desirable to assure that
../data/rfc/rfc2607.txt: transmission of accounting data is handled as an atomic
../data/rfc/rfc2607.txt- operation. This implies that all parties on the roaming
../data/rfc/rfc2607.txt- relationship path will receive and acknowledge the receipt of
../data/rfc/rfc2607.txt: the accounting data for the operation to complete. Proxies can
../data/rfc/rfc2607.txt: be used to ensure atomic delivery of accounting data by
../data/rfc/rfc2607.txt: arranging for delivery of the accounting data in a serial
../data/rfc/rfc2607.txt- fashion, as discussed in section 5.2.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-5. Proxy chaining
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- An example of a proxy chaining system is shown below.
--
../data/rfc/rfc2607.txt-RFC 2607 Proxy Chaining and Policy in Roaming June 1999
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- matches the reply with the request it sent earlier and forwards a
../data/rfc/rfc2607.txt- reply to the NAS. This model applies to all requests, including
../data/rfc/rfc2607.txt: Access Requests and Accounting Requests.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- Except for the two cases described below, a proxy server such as
../data/rfc/rfc2607.txt- Proxy2 in the diagram above SHOULD NOT send a Reply packet to Proxy1
../data/rfc/rfc2607.txt- without first having received a Reply packet initiated by the Home
../data/rfc/rfc2607.txt- Server. The two exceptions are when the proxy is enforcing policy as
../data/rfc/rfc2607.txt- described in section 5.1 and when the proxy is acting as an
../data/rfc/rfc2607.txt: accounting store (as in store and forward), as described in section
../data/rfc/rfc2607.txt- 5.2.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- The RADIUS protocol described in [3] does not provide for end-to-end
../data/rfc/rfc2607.txt- security services, including integrity or replay protection,
../data/rfc/rfc2607.txt- authentication or confidentiality. As noted in the security
--
../data/rfc/rfc2607.txt- <--------- <---------
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- A proxy MAY also decide to Reject a Request that has been accepted by
../data/rfc/rfc2607.txt- the home server. This could be based on the set of attributes
../data/rfc/rfc2607.txt- returned by the home server. In this case the Proxy SHOULD send an
../data/rfc/rfc2607.txt: Access-Reject to the NAS and an Accounting-Request with Acct-Status-
../data/rfc/rfc2607.txt- Type=Proxy-Stop (6) to the home server. This lets the home server
../data/rfc/rfc2607.txt- know that the session it approved has been denied downstream by the
../data/rfc/rfc2607.txt- proxy. However, a proxy MUST NOT send an Access-Accept after
../data/rfc/rfc2607.txt- receiving an Access-Reject from a proxy or from the home server.
../data/rfc/rfc2607.txt-
--
../data/rfc/rfc2607.txt- (Access-Reject) (Access-Accept) (Access-Accept) Server
../data/rfc/rfc2607.txt- <--------- <--------- <---------
../data/rfc/rfc2607.txt- (AcctPxStop) (AcctPxStop)
../data/rfc/rfc2607.txt- ----------> ---------->
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt:5.2. Accounting behavior
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- As described above, a proxy MUST NOT reply directly with an Access-
../data/rfc/rfc2607.txt- Accept, and MUST NOT reply with an Access-Accept when it has received
../data/rfc/rfc2607.txt- an Access-Reject from another proxy or Home Server. As a result, in
../data/rfc/rfc2607.txt: all cases where an accounting record is to be generated (accepted
../data/rfc/rfc2607.txt- sessions), no direct replies have occurred, and the Access-Request
../data/rfc/rfc2607.txt- and Access-Accept have passed through the same set of systems.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt: In order to allow proxies to match incoming Accounting-Requests with
../data/rfc/rfc2607.txt- previously handled Access-Requests and Access-Accepts, a proxy SHOULD
../data/rfc/rfc2607.txt: route the Accounting-Request along the same realm path travelled in
../data/rfc/rfc2607.txt- authentication/authorization. Note that this does not imply that
../data/rfc/rfc2607.txt: accounting packets will necessarily travel the identical path,
../data/rfc/rfc2607.txt- machine by machine, as did authentication/authorization packets.
../data/rfc/rfc2607.txt- This is because it is conceivable that a proxy may have gone down,
../data/rfc/rfc2607.txt: and as a result the Accounting-request may need to be forwarded to an
../data/rfc/rfc2607.txt- alternate server. It is also conceivable that
../data/rfc/rfc2607.txt: authentication/authorization and accounting may be handled by
../data/rfc/rfc2607.txt- different servers within a realm.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt: The Class attribute can be used to match Accounting Requests with
../data/rfc/rfc2607.txt- prior Access Requests. It can also be used to match session log
../data/rfc/rfc2607.txt- records between the home Server, proxies, and NAS. This matching can
../data/rfc/rfc2607.txt- be accomplished either in real-time (in the case that authentication
../data/rfc/rfc2607.txt: and accounting packets follow the same path, machine by machine), or
../data/rfc/rfc2607.txt- after the fact.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- Home servers SHOULD insert a unique session identifier in the Class
../data/rfc/rfc2607.txt- attribute in an Access-Accept and Access-Challenge. Proxies and
../data/rfc/rfc2607.txt- NASes MUST forward the unmodified Class attribute. The NAS MUST
../data/rfc/rfc2607.txt- include the Class attribute in subsequent requests, in particular for
../data/rfc/rfc2607.txt: Accounting-Requests. The sequence of events is shown below:
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-
--
../data/rfc/rfc2607.txt- --------> --------> --------->
../data/rfc/rfc2607.txt- NAS Proxy1 Proxy2 Home (add class)
../data/rfc/rfc2607.txt- <-class-- <-class- <-class--
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt: Accounting
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt: (Accounting-req) (Accounting-req) (Accounting-req)
../data/rfc/rfc2607.txt- w/class w/class w/class
../data/rfc/rfc2607.txt- NAS ----------> Proxy1 ----------> Proxy2 ----------> Home
../data/rfc/rfc2607.txt: (Accounting-reply) (Accounting-reply)(Accounting-reply) Server
../data/rfc/rfc2607.txt- <--------- <--------- <---------
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt: Since there is no need to implement policy in accounting, a proxy
../data/rfc/rfc2607.txt: MUST forward all Accounting Requests to the next server on the path.
../data/rfc/rfc2607.txt: The proxy MUST guarantee that the Accounting Request is received by
../data/rfc/rfc2607.txt- the End Server and all intermediate servers. The proxy may do this
../data/rfc/rfc2607.txt: either by: 1) forwarding the Accounting Request and not sending a
../data/rfc/rfc2607.txt- Reply until it receives the matching Reply from the upstream server,
../data/rfc/rfc2607.txt- or 2) acting as a store point which takes responsibility for
../data/rfc/rfc2607.txt: reforwarding the Accounting Request until it receives a Reply.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- Note that when the proxy does not send a reply until it receives a
../data/rfc/rfc2607.txt: matching reply, this ensures that Accounting Start and Stop messages
../data/rfc/rfc2607.txt- are received and can be logged by all servers along the roaming
../data/rfc/rfc2607.txt- relationship path. If one of the servers is not available, then the
../data/rfc/rfc2607.txt: operation will fail. As a result the entire accounting transaction
../data/rfc/rfc2607.txt- will either succeed or fail as a unit, and thus can be said to be
../data/rfc/rfc2607.txt- atomic.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- Where store and forward is implemented, it is possible that one or
../data/rfc/rfc2607.txt- more servers along the roaming relationship path will not receive the
../data/rfc/rfc2607.txt: accounting data while others will. The accounting operation will not
../data/rfc/rfc2607.txt- succeed or fail as a unit, and is therefore not atomic. As a result,
../data/rfc/rfc2607.txt- it may not be possible for the roaming partners to reconcile their
../data/rfc/rfc2607.txt- audit logs, opening new opportunities for fraud. Where store and
../data/rfc/rfc2607.txt: forward is implemented, forwarding of Accounting Requests SHOULD be
../data/rfc/rfc2607.txt- done as they are received so the downstream servers will receive them
../data/rfc/rfc2607.txt- in a timely way.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- Note that there are cases where a proxy will need to forward an
../data/rfc/rfc2607.txt: Accounting packet to more than one system. For example, in order to
../data/rfc/rfc2607.txt: allow for proper accounting in the case of a NAS that is shutting
../data/rfc/rfc2607.txt: down, the proxy can send an Accounting-Request with Acct-Status-
../data/rfc/rfc2607.txt: Type=Accounting-Off (8) to all realms that it forwards to. In turn,
../data/rfc/rfc2607.txt- these proxies will also flood the packet to their connected realms.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-Aboba & Vollbrecht Informational [Page 8]
--
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- [3] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
../data/rfc/rfc2607.txt- Authentication Dial In User Service (RADIUS)", RFC 2138, April
../data/rfc/rfc2607.txt- 1997.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt: [4] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
../data/rfc/rfc2607.txt- Levels", BCP 14, RFC 2119, March 1997.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- [6] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
--
../data/rfc/rfc2607.txt- security threats, including:
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- Message editing
../data/rfc/rfc2607.txt- Attribute editing
../data/rfc/rfc2607.txt- Theft of passwords
../data/rfc/rfc2607.txt: Theft and modification of accounting data
../data/rfc/rfc2607.txt- Replay attacks
../data/rfc/rfc2607.txt- Connection hijacking
../data/rfc/rfc2607.txt: Fraudulent accounting
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-7.1. Message editing
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- Through the use of shared secrets it is possible for proxies
../data/rfc/rfc2607.txt- operating in different domains to establish a trust relationship.
--
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- For example, an Access-Accept could be substituted for an Access-
../data/rfc/rfc2607.txt- Reject, and without end-to-end integrity protection, there is no way
../data/rfc/rfc2607.txt- for the NAS to detect this. On the home server, this will result in
../data/rfc/rfc2607.txt: an accounting log entry for a session that was not authorized.
../data/rfc/rfc2607.txt: However, if the proxy does not forward accounting packets or session
../data/rfc/rfc2607.txt- records to the home server, then the home server will not be able to
../data/rfc/rfc2607.txt- detect the discrepancy until a bill is received and audited.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- Note that a proxy can also send an Access-Reject to the NAS after
../data/rfc/rfc2607.txt- receiving an Access-Accept from the home server. This will result in
../data/rfc/rfc2607.txt: an authentication log entry without a corresponding accounting log
../data/rfc/rfc2607.txt: entry. Without the proxy sending an Accounting-Request with Acct-
../data/rfc/rfc2607.txt- Status-Type=Proxy-Stop (6) to the home server, then there will be no
../data/rfc/rfc2607.txt- way for the home server to determine whether the discrepancy is due
../data/rfc/rfc2607.txt: to policy implementation or loss of accounting packets. Thus the use
../data/rfc/rfc2607.txt- of Acct-Status-Type=Proxy-Stop can be of value in debugging roaming
../data/rfc/rfc2607.txt- systems.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- It should be noted that even if end-to-end security were to be
../data/rfc/rfc2607.txt- available, a number of sticky questions would remain. While the end-
--
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- provided to the client. The mismatch between requested and received
../data/rfc/rfc2607.txt- services may only be detectable after the fact by comparing the
../data/rfc/rfc2607.txt- Access-Accept attributes against the attributes included in the
../data/rfc/rfc2607.txt: Accounting-Request. However, without end-to-end security services, it
../data/rfc/rfc2607.txt- is possible for a rogue proxy to cover its tracks.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- Due to the complexity of proxy configuration, such attacks need not
../data/rfc/rfc2607.txt- involve malice, but can occur due to mis-configuration or
../data/rfc/rfc2607.txt- implementation deficiencies. Today several proxy implementations
--
../data/rfc/rfc2607.txt- confidentiality. As a result, where clients authenticate using PAP,
../data/rfc/rfc2607.txt- each proxy along the path between the local NAS and the home server
../data/rfc/rfc2607.txt- will have access to the cleartext password. In many circumstances,
../data/rfc/rfc2607.txt- this represents an unacceptable security risk.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt:7.4. Theft and modification of accounting data
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt: Typically in roaming systems, accounting packets are provided to all
../data/rfc/rfc2607.txt- the participants along the roaming relationship path, in order to
../data/rfc/rfc2607.txt- allow them to audit subsequent invoices. RADIUS as described in [3]
../data/rfc/rfc2607.txt- does not provide for end-to-end security services, including
../data/rfc/rfc2607.txt- integrity protection or confidentiality. Without end-to-end integrity
../data/rfc/rfc2607.txt: protection, it is possible for proxies to modify accounting packets
../data/rfc/rfc2607.txt: or session records. Without end-to-end confidentiality, accounting
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-Aboba & Vollbrecht Informational [Page 11]
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-RFC 2607 Proxy Chaining and Policy in Roaming June 1999
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- data will be accessible to proxies. However, if the objective is
../data/rfc/rfc2607.txt: merely to prevent snooping of accounting data on the wire, then IPSEC
../data/rfc/rfc2607.txt- ESP can be used.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-7.5. Replay attacks
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- In this attack, a man in the middle or rogue proxy collects CHAP-
../data/rfc/rfc2607.txt- Challenge and CHAP-Response attributes, and later replays them. If
../data/rfc/rfc2607.txt- this attack is performed in collaboration with an unscrupulous ISP,
../data/rfc/rfc2607.txt: it can be used to subsequently submit fraudulent accounting records
../data/rfc/rfc2607.txt- for payment. The system performing the replay need not necessarily
../data/rfc/rfc2607.txt- be the one that initially captured the CHAP Challenge/Response pair.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- While RADIUS as described in [3] is vulnerable to replay attacks,
../data/rfc/rfc2607.txt- without roaming the threat is restricted to proxies operating in the
--
../data/rfc/rfc2607.txt- In this form of attack, the attacker attempts to inject packets into
../data/rfc/rfc2607.txt- the conversation between the NAS and the home server. RADIUS as
../data/rfc/rfc2607.txt- described in [3] is vulnerable to such attacks since only Access-
../data/rfc/rfc2607.txt- Reply and Access-Challenge packets are authenticated.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt:7.7. Fraudulent accounting
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt: In this form of attack, a local proxy transmits fraudulent accounting
../data/rfc/rfc2607.txt- packets or session records in an effort to collect fees to which they
../data/rfc/rfc2607.txt- are not entitled. This includes submission of packets or session
../data/rfc/rfc2607.txt- records for non-existent sessions. Since in RADIUS as described in
../data/rfc/rfc2607.txt- [3], there is no end-to-end security, a rogue proxy may insert or
../data/rfc/rfc2607.txt- edit packets without fear of detection.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt: In order to detect submissions of accounting packets or session
../data/rfc/rfc2607.txt: records for non-existent sessions, parties receiving accounting
../data/rfc/rfc2607.txt- packets or session records would be prudent to reconcile them with
../data/rfc/rfc2607.txt- the authentication logs. Such reconciliation is only typically
../data/rfc/rfc2607.txt- possible when the party acts as an authentication proxy for all
../data/rfc/rfc2607.txt: sessions for which an accounting record will subsequently be
../data/rfc/rfc2607.txt- submitted.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- In order to make reconciliation easier, home servers involved in
../data/rfc/rfc2607.txt- roaming include a Class attribute in the Access-Accept. The Class
../data/rfc/rfc2607.txt- attribute uniquely identifies a session, so as to allow an
../data/rfc/rfc2607.txt- authentication log entry to be matched with a corresponding
../data/rfc/rfc2607.txt: accounting packet or session record.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-Aboba & Vollbrecht Informational [Page 12]
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-RFC 2607 Proxy Chaining and Policy in Roaming June 1999
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt: If reconciliation is put in place and all accounting log entries
../data/rfc/rfc2607.txt- without a corresponding authentication are rejected, then the
../data/rfc/rfc2607.txt- attacker will need to have obtained a valid user password prior to
../data/rfc/rfc2607.txt: submitting accounting packets or session records on non-existent
../data/rfc/rfc2607.txt- sessions. While use of end-to-end security can defeat unauthorized
../data/rfc/rfc2607.txt: injection or editing of accounting or authentication packets by
../data/rfc/rfc2607.txt- intermediate proxies, other attacks remain feasible. For example,
../data/rfc/rfc2607.txt- unless replay protection is put in place, it is still feasible for an
../data/rfc/rfc2607.txt: intermediate proxy to resubmit authentication or accounting packets
../data/rfc/rfc2607.txt- or session records. In addition, end-to-end security does not provide
../data/rfc/rfc2607.txt- protection against attacks by the local proxy, since this is
../data/rfc/rfc2607.txt- typically where end-to-end security will be initiated. To detect such
../data/rfc/rfc2607.txt- attacks, other measures need to be put in place, such as systems for
../data/rfc/rfc2607.txt- detecting unusual activity of ISP or user accounts, or for
../data/rfc/rfc2607.txt- determining whether a user or ISP account is within their credit
../data/rfc/rfc2607.txt- limit.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- Note that implementation of the store and forward approach to proxy
../data/rfc/rfc2607.txt: accounting makes it possible for some systems in the roaming
../data/rfc/rfc2607.txt: relationship path to receive accounting records that other systems do
../data/rfc/rfc2607.txt- not get. This can result in audit discrepancies. About the best that
../data/rfc/rfc2607.txt: is achievable in such cases is to verify that the accounting data is
../data/rfc/rfc2607.txt- missing by checking against the authentication logs.
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt-8. Acknowledgments
../data/rfc/rfc2607.txt-
../data/rfc/rfc2607.txt- Thanks to Pat Calhoun of Sun Microsystems, Mark Beadles of
--
../data/rfc/rfc4784.txt- The Verizon Wireless Dynamic Mobile IP Key Update procedure is a
../data/rfc/rfc4784.txt- mechanism for distributing and updating Mobile IP (MIP) cryptographic
../data/rfc/rfc4784.txt- keys in cdma2000(R) networks (including High Rate Packet Data, which
../data/rfc/rfc4784.txt- is often referred to as 1xEV-DO). The Dynamic Mobile IP Key Update
../data/rfc/rfc4784.txt- (DMU) procedure occurs between the MIP Mobile Node (MN) and RADIUS
../data/rfc/rfc4784.txt: Authentication, Authorization and Accounting (AAA) Server via a
../data/rfc/rfc4784.txt- cdma2000(R) Packet Data Serving Node (PDSN) that is acting as a
../data/rfc/rfc4784.txt- Mobile IP Foreign Agent (FA).
../data/rfc/rfc4784.txt-
../data/rfc/rfc4784.txt- cdma2000(R) is a registered trademark of the Telecommunications
../data/rfc/rfc4784.txt- Industry Association (TIA).
--
../data/rfc/rfc4784.txt- mechanism for distributing and updating Mobile IP (MIP) cryptographic
../data/rfc/rfc4784.txt- keys in cdma2000(R) 1xRTT (1X) [2] and High Rate Packet Data (HRPD) /
../data/rfc/rfc4784.txt- 1xEV-DO networks [3]. The Dynamic Mobile IP Key Update (DMU)
../data/rfc/rfc4784.txt- procedure occurs between the Mobile IP Mobile Node (MN) and the home
../data/rfc/rfc4784.txt- RADIUS [4] (or Diameter [5]) Authentication, Authorization and
../data/rfc/rfc4784.txt: Accounting (AAA) Server via a cdma2000(R) Packet Data Serving Node
../data/rfc/rfc4784.txt- (PDSN) that is acting as a Mobile IP Foreign Agent (FA). (In this
../data/rfc/rfc4784.txt- document, we use the acronym AAAH to indicate the home AAA server as
../data/rfc/rfc4784.txt- opposed to an AAA server that may be located in a visited system.)
../data/rfc/rfc4784.txt- This procedure is intended to support wireless systems conforming to
../data/rfc/rfc4784.txt- Telecommunications Industry Association (TIA) TR-45 Standard IS-835
--
../data/rfc/rfc3654.txt- packet processing and handling. By allowing the control and
../data/rfc/rfc3654.txt- forwarding planes to evolve independently, different types of FEs can
../data/rfc/rfc3654.txt- be developed - some general purpose and others more specialized.
../data/rfc/rfc3654.txt- Some functions that FEs could perform include layer 3 forwarding,
../data/rfc/rfc3654.txt- metering, shaping, firewall, NAT, encapsulation (e.g., tunneling),
../data/rfc/rfc3654.txt: decapsulation, encryption, accounting, etc. Nearly all combinations
../data/rfc/rfc3654.txt- of these functions may be present in practical FEs.
../data/rfc/rfc3654.txt-
../data/rfc/rfc3654.txt- Below is a diagram illustrating an example NE composed of a CE and
../data/rfc/rfc3654.txt- two FEs. Both FEs and CE require minimal configuration as part of
../data/rfc/rfc3654.txt- the pre-configuration process and this may be done by FE Manager and
--
../data/rfc/rfc3654.txt- The model MUST be capable of describing the order in which these
../data/rfc/rfc3654.txt- logical functions are applied in a FE. The ordering of logical
../data/rfc/rfc3654.txt- functions is important in many cases. For example, a NAT function
../data/rfc/rfc3654.txt- may change a packet's source or destination IP address. Any number
../data/rfc/rfc3654.txt- of other logical functions (e.g., layer 3 forwarding, ingress/egress
../data/rfc/rfc3654.txt: firewall, shaping, and accounting) may make use of the source or
../data/rfc/rfc3654.txt- destination IP address when making decisions. The CE needs to know
../data/rfc/rfc3654.txt- whether to configure these logical functions with the pre-NAT or
../data/rfc/rfc3654.txt- post-NAT IP address. Furthermore, the model MUST be capable of
../data/rfc/rfc3654.txt- expressing multiple instances of the same logical function in a FE's
../data/rfc/rfc3654.txt- processing path. Using NAT again as an example, one NAT function is
--
../data/rfc/rfc3654.txt- events as well. This Does NOT mean off-loading of any piece of code
../data/rfc/rfc3654.txt- to an FE, just that the FE Model should be able to express existing
../data/rfc/rfc3654.txt- Off-loaded functions on an FE.
../data/rfc/rfc3654.txt-
../data/rfc/rfc3654.txt- 9) IPFLOW/PSAMP Functions
../data/rfc/rfc3654.txt: Several applications such as, Usage-based Accounting, Traffic
../data/rfc/rfc3654.txt- engineering, require flow-based IP traffic measurements from Network
../data/rfc/rfc3654.txt- Elements. [IPFLOW] defines architecture for IP traffic flow
../data/rfc/rfc3654.txt- monitoring, measuring and exporting. The FE model SHOULD be able to
../data/rfc/rfc3654.txt: express metering functions and flow accounting needed for exporting
../data/rfc/rfc3654.txt- IP traffic flow information. Similarly to support measurement-based
../data/rfc/rfc3654.txt- applications, [PSAMP] describes a framework to define a standard set
../data/rfc/rfc3654.txt- of capabilities for network elements to sample subsets of packets by
../data/rfc/rfc3654.txt- statistical and other methods. The FE model SHOULD be able to
../data/rfc/rfc3654.txt- express statistical packet filtering functions and packet information
--
../data/rfc/rfc8404.txt- 2.2.3. Network-Congestion Management . . . . . . . . . . . . 16
../data/rfc/rfc8404.txt- 2.2.4. Performance-Enhancing Proxies . . . . . . . . . . . . 16
../data/rfc/rfc8404.txt- 2.2.5. Caching and Content Replication near the Network Edge 17
../data/rfc/rfc8404.txt- 2.2.6. Content Compression . . . . . . . . . . . . . . . . . 18
../data/rfc/rfc8404.txt- 2.2.7. Service Function Chaining . . . . . . . . . . . . . . 18
../data/rfc/rfc8404.txt: 2.3. Content Filtering, Network Access, and Accounting . . . . 19
../data/rfc/rfc8404.txt- 2.3.1. Content Filtering . . . . . . . . . . . . . . . . . . 19
../data/rfc/rfc8404.txt- 2.3.2. Network Access and Data Usage . . . . . . . . . . . . 20
../data/rfc/rfc8404.txt- 2.3.3. Application Layer Gateways (ALGs) . . . . . . . . . . 21
../data/rfc/rfc8404.txt- 2.3.4. HTTP Header Insertion . . . . . . . . . . . . . . . . 22
../data/rfc/rfc8404.txt- 3. Encryption in Hosting and Application SP Environments . . . . 23
--
../data/rfc/rfc8404.txt- In the SFC case, the layer below a network service header can be
../data/rfc/rfc8404.txt- protected with session encryption. A goal is protecting end-user
../data/rfc/rfc8404.txt- data, while retaining the intended functions of RFC 7665 [RFC7665] at
../data/rfc/rfc8404.txt- the same time.
../data/rfc/rfc8404.txt-
../data/rfc/rfc8404.txt:2.3. Content Filtering, Network Access, and Accounting
../data/rfc/rfc8404.txt-
../data/rfc/rfc8404.txt- Mobile networks and many ISPs operate under the regulations of their
../data/rfc/rfc8404.txt- licensing government authority. These regulations include Lawful
../data/rfc/rfc8404.txt- Intercept, adherence to Codes of Practice on content filtering, and
../data/rfc/rfc8404.txt- application of court order filters. Such regulations assume network
../data/rfc/rfc8404.txt: access to provide content filtering and accounting, as discussed
../data/rfc/rfc8404.txt- below. As previously stated, the intent of this document is to
../data/rfc/rfc8404.txt- document existing practices; the development of IETF protocols
../data/rfc/rfc8404.txt- follows the guiding principles of [RFC1984] and [RFC2804] and
../data/rfc/rfc8404.txt- explicitly does not support tools and methods that could be used for
../data/rfc/rfc8404.txt- wiretapping and censorship.
--
../data/rfc/rfc8404.txt-
../data/rfc/rfc8404.txt- However, there are cases (beyond parental control) when a network
../data/rfc/rfc8404.txt- service provider currently redirects customer requests for content
../data/rfc/rfc8404.txt- (affecting content accessibility):
../data/rfc/rfc8404.txt-
../data/rfc/rfc8404.txt: 1. The network service provider is performing the accounting and
../data/rfc/rfc8404.txt- billing for the content provider, and the customer has not (yet)
../data/rfc/rfc8404.txt- purchased the requested content.
../data/rfc/rfc8404.txt-
../data/rfc/rfc8404.txt- 2. Further content may not be allowed as the customer has reached
../data/rfc/rfc8404.txt- their usage limit and needs to purchase additional data service,
--
../data/rfc/rfc8404.txt-3.1.1. Monitoring Customer Access
../data/rfc/rfc8404.txt-
../data/rfc/rfc8404.txt- Hosted applications that allow some level of customer-management
../data/rfc/rfc8404.txt- access may also require monitoring by the hosting service provider.
../data/rfc/rfc8404.txt- Monitoring could include access-control restrictions such as
../data/rfc/rfc8404.txt: authentication, authorization, and accounting for filtering and
../data/rfc/rfc8404.txt- firewall rules to ensure they are continuously met. Customer access
../data/rfc/rfc8404.txt- may occur on multiple levels, including user-level and administrative
../data/rfc/rfc8404.txt- access. The hosting service provider may need to monitor access
../data/rfc/rfc8404.txt- through either session monitoring or log evaluation to ensure
../data/rfc/rfc8404.txt- security SLAs for access management are met. The use of session
--
../data/rfc/rfc8404.txt- Information Export (IPFIX), a flow-based protocol used to export
../data/rfc/rfc8404.txt- information about network flows.
../data/rfc/rfc8404.txt-
../data/rfc/rfc8404.txt-6.1. IP Flow Information Export
../data/rfc/rfc8404.txt-
../data/rfc/rfc8404.txt: Many of the accounting, monitoring, and measurement tasks described
../data/rfc/rfc8404.txt- in this document, especially in Sections 2.3.2, 3.1.1, 4.1.3, 4.2,
../data/rfc/rfc8404.txt- and 5.2, use the IPFIX protocol [RFC7011] for export and storage of
../data/rfc/rfc8404.txt- the monitored information. IPFIX evolved from the widely deployed
../data/rfc/rfc8404.txt- NetFlow protocol [RFC3954], which exports information about flows
../data/rfc/rfc8404.txt- identified by 5-tuple. While NetFlow was largely concerned with
../data/rfc/rfc8404.txt: exporting per-flow byte and packet counts for accounting purposes,
../data/rfc/rfc8404.txt- IPFIX's extensible Information Model [RFC7012] provides a variety of
../data/rfc/rfc8404.txt- Information Elements (IEs) [IPFIX-IANA] for representing information
../data/rfc/rfc8404.txt- above and below the traditional network-layer flow information.
../data/rfc/rfc8404.txt- Enterprise-specific IEs allow exporter vendors to define their own
../data/rfc/rfc8404.txt- non-standard IEs as well, and many of these are driven by header and
--
../data/rfc/rfc8582.txt-
../data/rfc/rfc8582.txt-
../data/rfc/rfc8582.txt-9. IANA Considerations
../data/rfc/rfc8582.txt-
../data/rfc/rfc8582.txt- IANA has registered the following values in the "Authentication,
../data/rfc/rfc8582.txt: Authorization, and Accounting (AAA) Parameters" registry:
../data/rfc/rfc8582.txt-
../data/rfc/rfc8582.txt- One new AVP code is defined in Section 7.2.1.
../data/rfc/rfc8582.txt-
../data/rfc/rfc8582.txt- One new OC-Feature-Vector AVP value is defined in Section 7.1.1.
../data/rfc/rfc8582.txt-
--
../data/rfc/rfc2165.txt-
../data/rfc/rfc2165.txt- DA Advertisement Replies may arrive from different sources, similar
../data/rfc/rfc2165.txt- in form to:
../data/rfc/rfc2165.txt-
../data/rfc/rfc2165.txt- URL returned: service:directory-agent://slp-resolver.catch22.com
../data/rfc/rfc2165.txt: Scope returned: ACCOUNTING
../data/rfc/rfc2165.txt-
../data/rfc/rfc2165.txt- URL returned: service:directory-agent://204.182.15.66 Scope
../data/rfc/rfc2165.txt- returned: JANITORIAL SERVICES
../data/rfc/rfc2165.txt-
../data/rfc/rfc2165.txt- The DA Advertisement format is defined in Section 14.
--
../data/rfc/rfc5591.txt- following constraints:
../data/rfc/rfc5591.txt-
../data/rfc/rfc5591.txt- 1. In times of network stress, the security protocol and its
../data/rfc/rfc5591.txt- underlying security mechanisms SHOULD NOT depend solely upon the
../data/rfc/rfc5591.txt- ready availability of other network services (e.g., Network Time
../data/rfc/rfc5591.txt: Protocol (NTP) or Authentication, Authorization, and Accounting
../data/rfc/rfc5591.txt- (AAA) protocols).
../data/rfc/rfc5591.txt-
../data/rfc/rfc5591.txt- 2. When the network is not under stress, the Security Model and its
../data/rfc/rfc5591.txt- underlying security mechanisms MAY depend upon the ready
../data/rfc/rfc5591.txt- availability of other network services.
--
../data/rfc/rfc7174.txt-
../data/rfc/rfc7174.txt- - Fault Management
../data/rfc/rfc7174.txt-
../data/rfc/rfc7174.txt- - Configuration Management
../data/rfc/rfc7174.txt-
../data/rfc/rfc7174.txt: - Accounting Management
../data/rfc/rfc7174.txt-
../data/rfc/rfc7174.txt- - Performance Management
../data/rfc/rfc7174.txt-
../data/rfc/rfc7174.txt- - Security Management
../data/rfc/rfc7174.txt-
--
../data/rfc/rfc6392.txt- replication. CDNs offer fast and reliable applications and services
../data/rfc/rfc6392.txt- by distributing content to cache or edge servers located close to
../data/rfc/rfc6392.txt- users. See [14] for an additional taxonomy and survey.
../data/rfc/rfc6392.txt-
../data/rfc/rfc6392.txt- A CDN has some combination of content delivery, request routing,
../data/rfc/rfc6392.txt: distribution, and accounting infrastructures. The content-delivery
../data/rfc/rfc6392.txt- infrastructure consists of a set of edge servers (also called
../data/rfc/rfc6392.txt- surrogates) that deliver copies of content to end users. The
../data/rfc/rfc6392.txt- request-routing infrastructure is responsible for directing client
../data/rfc/rfc6392.txt- requests to appropriate edge servers. It also interacts with the
../data/rfc/rfc6392.txt- distribution infrastructure to keep an up-to-date view of the content
../data/rfc/rfc6392.txt- stored in the CDN caches. The distribution infrastructure moves
../data/rfc/rfc6392.txt- content from the origin server to the CDN edge servers and ensures
../data/rfc/rfc6392.txt: consistency of content in the caches. The accounting infrastructure
../data/rfc/rfc6392.txt- maintains logs of client accesses and records the usage of the CDN
../data/rfc/rfc6392.txt- servers. This information is used for traffic reporting and usage-
../data/rfc/rfc6392.txt- based billing.
../data/rfc/rfc6392.txt-
../data/rfc/rfc6392.txt- In practice, a CDN typically hosts static content including images,
--
../data/rfc/rfc6150.txt- of MS-CHAP are also supported by RADIUS [RFC2548] and the
../data/rfc/rfc6150.txt- Extensible Authentication Protocol (EAP) [RFC5281]. In 2007,
../data/rfc/rfc6150.txt- [RFC4962] listed MS-CHAP v1 and v2 as flawed and recommended
../data/rfc/rfc6150.txt- against their use; these incidents were presented as a strong
../data/rfc/rfc6150.txt- indication for the necessity of built-in crypto-algorithm
../data/rfc/rfc6150.txt: agility in Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc6150.txt- protocols.
../data/rfc/rfc6150.txt-
../data/rfc/rfc6150.txt-
../data/rfc/rfc6150.txt-
../data/rfc/rfc6150.txt-
--
../data/rfc/rfc6150.txt- [RFC4757] Jaganathan, K., Zhu, L., and J. Brezak, "The RC4-HMAC
../data/rfc/rfc6150.txt- Kerberos Encryption Types Used by Microsoft Windows", RFC
../data/rfc/rfc6150.txt- 4757, December 2006.
../data/rfc/rfc6150.txt-
../data/rfc/rfc6150.txt- [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
../data/rfc/rfc6150.txt: Authorization, and Accounting (AAA) Key Management", BCP
../data/rfc/rfc6150.txt- 132, RFC 4962, July 2007.
../data/rfc/rfc6150.txt-
../data/rfc/rfc6150.txt- [RFC5126] Pinkas, D., Pope, N., and J. Ross, "CMS Advanced
../data/rfc/rfc6150.txt- Electronic Signatures (CAdES)", RFC 5126, March 2008.
../data/rfc/rfc6150.txt-
--
../data/rfc/rfc1374.txt- kilobytes of user data consists of "n" full bursts and one short
../data/rfc/rfc1374.txt- burst equal in length to the number of bytes in the HIPPI, LLC, IP
../data/rfc/rfc1374.txt- and TCP headers. "Hold Time" is the minimum connection duration
../data/rfc/rfc1374.txt- needed to send the packets. "Burst Rate" is the effective transfer
../data/rfc/rfc1374.txt- rate for the duration of the connection, not counting connection
../data/rfc/rfc1374.txt: switching time. Throughput rates are in megabytes/second, accounting
../data/rfc/rfc1374.txt- for connection switching times of 10, 30, 60, 90, 120 and 150
../data/rfc/rfc1374.txt- microseconds. These calculations ignore any limit on the rate at
../data/rfc/rfc1374.txt-
../data/rfc/rfc1374.txt-
../data/rfc/rfc1374.txt-
--
../data/rfc/rfc5706.txt- 3.3.2. Fault Determination ................................19
../data/rfc/rfc5706.txt- 3.3.3. Root Cause Analysis ................................20
../data/rfc/rfc5706.txt- 3.3.4. Fault Isolation ....................................20
../data/rfc/rfc5706.txt- 3.4. Configuration Management ..................................20
../data/rfc/rfc5706.txt- 3.4.1. Verifying Correct Operation ........................22
../data/rfc/rfc5706.txt: 3.5. Accounting Management .....................................22
../data/rfc/rfc5706.txt- 3.6. Performance Management ....................................22
../data/rfc/rfc5706.txt- 3.6.1. Monitoring the Protocol ............................23
../data/rfc/rfc5706.txt- 3.6.2. Monitoring the Device ..............................24
../data/rfc/rfc5706.txt- 3.6.3. Monitoring the Network .............................24
../data/rfc/rfc5706.txt- 3.6.4. Monitoring the Service .............................25
--
../data/rfc/rfc5706.txt- and
../data/rfc/rfc5706.txt-
../data/rfc/rfc5706.txt- o NETCONF Configuration Protocol [RFC4741]
../data/rfc/rfc5706.txt-
../data/rfc/rfc5706.txt- o the IP Flow Information Export (IPFIX) Protocol [RFC5101]) for
../data/rfc/rfc5706.txt: usage accounting
../data/rfc/rfc5706.txt-
../data/rfc/rfc5706.txt- o the syslog protocol [RFC5424] for logging
../data/rfc/rfc5706.txt-
../data/rfc/rfc5706.txt- Interoperability needs to be considered on the syntactic level and
../data/rfc/rfc5706.txt- the semantic level. While it can be irritating and time-consuming,
--
../data/rfc/rfc5706.txt- functioning of the protocol, and whether that is verified by testing
../data/rfc/rfc5706.txt- the service function and/or by testing the forwarding function of
../data/rfc/rfc5706.txt- each network element. This may be achieved through status and
../data/rfc/rfc5706.txt- statistical information gathered from devices.
../data/rfc/rfc5706.txt-
../data/rfc/rfc5706.txt:3.5. Accounting Management
../data/rfc/rfc5706.txt-
../data/rfc/rfc5706.txt- A protocol designer should consider whether it would be appropriate
../data/rfc/rfc5706.txt- to collect usage information related to this protocol and, if so,
../data/rfc/rfc5706.txt- what usage information would be appropriate to collect.
../data/rfc/rfc5706.txt-
../data/rfc/rfc5706.txt: "Introduction to Accounting Management" [RFC2975] discusses a number
../data/rfc/rfc5706.txt- of factors relevant to monitoring usage of protocols for purposes of
../data/rfc/rfc5706.txt- capacity and trend analysis, cost allocation, auditing, and billing.
../data/rfc/rfc5706.txt- The document also discusses how some existing protocols can be used
../data/rfc/rfc5706.txt- for these purposes. These factors should be considered when
../data/rfc/rfc5706.txt- designing a protocol whose usage might need to be monitored or when
../data/rfc/rfc5706.txt: recommending a protocol to do usage accounting.
../data/rfc/rfc5706.txt-
../data/rfc/rfc5706.txt-3.6. Performance Management
../data/rfc/rfc5706.txt-
../data/rfc/rfc5706.txt- From a manageability point of view, it is important to determine how
../data/rfc/rfc5706.txt- well a network deploying the protocol or technology defined in the
--
../data/rfc/rfc5706.txt- [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
../data/rfc/rfc5706.txt- "Remote Authentication Dial In User Service (RADIUS)",
../data/rfc/rfc5706.txt- RFC 2865, June 2000.
../data/rfc/rfc5706.txt-
../data/rfc/rfc5706.txt- [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to
../data/rfc/rfc5706.txt: Accounting Management", RFC 2975, October 2000.
../data/rfc/rfc5706.txt-
../data/rfc/rfc5706.txt-
../data/rfc/rfc5706.txt-
../data/rfc/rfc5706.txt-
../data/rfc/rfc5706.txt-Harrington Informational [Page 29]
--
../data/rfc/rfc5706.txt- protocols in the network? Will it impact performance (e.g.,
../data/rfc/rfc5706.txt- jitter) of certain types of applications running in the same
../data/rfc/rfc5706.txt- network?
../data/rfc/rfc5706.txt-
../data/rfc/rfc5706.txt- * Does the new protocol need supporting services (e.g., DNS or
../data/rfc/rfc5706.txt: Authentication, Authorization, and Accounting - AAA) added to
../data/rfc/rfc5706.txt- an existing network?
../data/rfc/rfc5706.txt-
../data/rfc/rfc5706.txt- 6. Have suggestions for verifying correct operation been discussed?
../data/rfc/rfc5706.txt- See Section 2.6.
../data/rfc/rfc5706.txt-
--
../data/rfc/rfc5706.txt-Harrington Informational [Page 34]
../data/rfc/rfc5706.txt-
../data/rfc/rfc5706.txt-RFC 5706 Ops and Mgmt Guidelines November 2009
../data/rfc/rfc5706.txt-
../data/rfc/rfc5706.txt-
../data/rfc/rfc5706.txt: 5. Is accounting management discussed? See Section 3.5.
../data/rfc/rfc5706.txt-
../data/rfc/rfc5706.txt- 6. Is performance management discussed? See Section 3.6.
../data/rfc/rfc5706.txt-
../data/rfc/rfc5706.txt- * Does the protocol have an impact on network traffic and
../data/rfc/rfc5706.txt- network devices? Can performance be measured?
--
../data/rfc/rfc164.txt- o Are looking for an NCP implementer.
../data/rfc/rfc164.txt-
../data/rfc/rfc164.txt- o Will use other services; laser store and UCSB.
../data/rfc/rfc164.txt-
../data/rfc/rfc164.txt- o Their general research includes an interest in Network
../data/rfc/rfc164.txt: accounting and management.
../data/rfc/rfc164.txt-
../data/rfc/rfc164.txt- o Will go onto Net as soon as possible to ILLINOIS.
../data/rfc/rfc164.txt-
../data/rfc/rfc164.txt- o Will go on via TIP if it can support two nodes.
../data/rfc/rfc164.txt-
--
../data/rfc/rfc164.txt- sufficient to have only one connection with each site.
../data/rfc/rfc164.txt-
../data/rfc/rfc164.txt- On software development, the NCP progress has been extremely poor and
../data/rfc/rfc164.txt- slow. The second iteration should have been defined by now from
../data/rfc/rfc164.txt- experiences with the first. Towards the end of the year a new
../data/rfc/rfc164.txt: protocol should be defined to last for a couple of years. Accounting
../data/rfc/rfc164.txt- and billing protocol should also be defined. The NCP protocol is
../data/rfc/rfc164.txt- getting to be a critical problem -- everyone should be complete and
../data/rfc/rfc164.txt- consistent with the current protocol by July 1. Without it, there
../data/rfc/rfc164.txt- will be serious problems of bringing new people onto the Net. For
../data/rfc/rfc164.txt- example, the I4 and the laser store will be on the Net by March or
--
../data/rfc/rfc4672.txt- Authorization extensions on the network access server (NAS) devices
../data/rfc/rfc4672.txt- to handle the Disconnect and Change-of-Authorization (CoA) messages,
../data/rfc/rfc4672.txt- as described in [RFC3576]. As a result, the effective management of
../data/rfc/rfc4672.txt- RADIUS Dynamic Authorization entities is of considerable importance.
../data/rfc/rfc4672.txt- This RADIUS Dynamic Authorization Client MIB complements the managed
../data/rfc/rfc4672.txt: objects used for managing RADIUS authentication and accounting
../data/rfc/rfc4672.txt- servers, as described in [RFC4669] and [RFC4671], respectively.
../data/rfc/rfc4672.txt-
../data/rfc/rfc4672.txt-1.1. Requirements Notation
../data/rfc/rfc4672.txt-
../data/rfc/rfc4672.txt- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
--
../data/rfc/rfc4672.txt- Standard Management Framework", RFC 3410, December 2002.
../data/rfc/rfc4672.txt-
../data/rfc/rfc4672.txt- [RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6",
../data/rfc/rfc4672.txt- RFC 4669, August 2006.
../data/rfc/rfc4672.txt-
../data/rfc/rfc4672.txt: [RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6", RFC
../data/rfc/rfc4672.txt- 4671, August 2006.
../data/rfc/rfc4672.txt-
../data/rfc/rfc4672.txt-
../data/rfc/rfc4672.txt-
../data/rfc/rfc4672.txt-De Cnodder, et al. Informational [Page 21]
--
../data/rfc/rfc4080.txt- In some cases, it is desired to be able to initiate and/or terminate
../data/rfc/rfc4080.txt- NSIS signaling not from the end host that sends/receives the data
../data/rfc/rfc4080.txt- flow, but from some other entities in the network that can be called
../data/rfc/rfc4080.txt- signaling proxies. There could be various reasons for this:
../data/rfc/rfc4080.txt- signaling on behalf of the end hosts that are not NSIS-aware,
../data/rfc/rfc4080.txt: consolidation of the customer accounting (authentication,
../data/rfc/rfc4080.txt- authorization) in respect to consumed application and transport
../data/rfc/rfc4080.txt- resources, security considerations, limitation of the physical
../data/rfc/rfc4080.txt- connection between host and network, and so on. This configuration
../data/rfc/rfc4080.txt- can be considered a kind of "proxy on the data path"; see Figure 2.
../data/rfc/rfc4080.txt-
--
../data/rfc/rfc4080.txt- deployment comes from a restriction of the number of impacted nodes
../data/rfc/rfc4080.txt- in case of deployment and/or upgrade of an NSLP. Path-decoupled
../data/rfc/rfc4080.txt- signaling would allow, for instance, deploying a solution without
../data/rfc/rfc4080.txt- upgrading any of the routers in the data plane. Additional
../data/rfc/rfc4080.txt- functionality that can be supported includes the use of off-path
../data/rfc/rfc4080.txt: proxies to support authorization or accounting architectures.
../data/rfc/rfc4080.txt-
../data/rfc/rfc4080.txt- There are potentially significant differences in the way that the two
../data/rfc/rfc4080.txt- signaling paradigms should be analyzed. Using a single centralized
../data/rfc/rfc4080.txt- off-path NE may increase the requirements in terms of message
../data/rfc/rfc4080.txt- handling; on the other hand, path-decoupled signaling is equally
--
../data/rfc/rfc4080.txt- When state has been installed along the new path, the existing state
../data/rfc/rfc4080.txt- on the old path needs to be removed. With the soft-state principle,
../data/rfc/rfc4080.txt- this will happen automatically because of the lack of refresh
../data/rfc/rfc4080.txt- messages. Depending on the refresh timer, however, it may be
../data/rfc/rfc4080.txt- required to tear down this state much faster (e.g., because it is
../data/rfc/rfc4080.txt: tied to an accounting record). In that case, the teardown message
../data/rfc/rfc4080.txt- needs to be able to distinguish between the new path and the old
../data/rfc/rfc4080.txt- path.
../data/rfc/rfc4080.txt-
../data/rfc/rfc4080.txt- In some environments, it is desirable to provide connectivity and
../data/rfc/rfc4080.txt- per-flow or per-class state management with high-availability
--
../data/rfc/rfc4080.txt-
../data/rfc/rfc4080.txt- [11] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on
../data/rfc/rfc4080.txt- Security Considerations", BCP 72, RFC 3552, July 2003.
../data/rfc/rfc4080.txt-
../data/rfc/rfc4080.txt- [12] Tschofenig, H., "NSIS Authentication, Authorization and
../data/rfc/rfc4080.txt: Accounting Issues", Work in Progress, March 2003.
../data/rfc/rfc4080.txt-
../data/rfc/rfc4080.txt- [13] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S.
../data/rfc/rfc4080.txt- Molendini, "RSVP Refresh Overhead Reduction Extensions",
../data/rfc/rfc4080.txt- RFC 2961, April 2001.
../data/rfc/rfc4080.txt-
--
../data/rfc/rfc8011.txt- the Client software automatically supplies the Document name on
../data/rfc/rfc8011.txt- behalf of the End User by using a file name or an
../data/rfc/rfc8011.txt- application-generated name. If this attribute is supplied, its
../data/rfc/rfc8011.txt- value can be used in a manner defined by each implementation.
../data/rfc/rfc8011.txt- Examples include the following: printed along with the Job (Job
../data/rfc/rfc8011.txt: start sheet, page adornments, etc.), used by accounting or
../data/rfc/rfc8011.txt- resource-tracking management tools, or even stored along with
../data/rfc/rfc8011.txt- the Document as a Document-level attribute.
../data/rfc/rfc8011.txt-
../data/rfc/rfc8011.txt- "compression" (type2 keyword):
../data/rfc/rfc8011.txt-
--
../data/rfc/rfc8011.txt- operation has been performed, a Printer MUST return no Jobs in
../data/rfc/rfc8011.txt- subsequent Get-Job-Attributes and Get-Jobs responses (until new Jobs
../data/rfc/rfc8011.txt- are submitted).
../data/rfc/rfc8011.txt-
../data/rfc/rfc8011.txt- Note: This operation SHOULD NOT be supported in new implementations,
../data/rfc/rfc8011.txt: since it destroys Printer accounting information.
../data/rfc/rfc8011.txt-
../data/rfc/rfc8011.txt- Whether the Purge-Jobs (and Get-Jobs) operation affects Jobs that
../data/rfc/rfc8011.txt- were submitted to the device from sources other than the IPP Printer
../data/rfc/rfc8011.txt- in the same way that the Purge-Jobs operation affects Jobs that were
../data/rfc/rfc8011.txt- submitted to the IPP Printer using IPP depends on implementation,
--
../data/rfc/rfc8011.txt- This DEPRECATED operation allows a Client to restart a Job that is
../data/rfc/rfc8011.txt- retained in the queue after processing has completed (see
../data/rfc/rfc8011.txt- Section 5.3.7.2).
../data/rfc/rfc8011.txt-
../data/rfc/rfc8011.txt- Note: This operation SHOULD NOT be supported in new implementations,
../data/rfc/rfc8011.txt: since it destroys Printer accounting information. The Resubmit-Job
../data/rfc/rfc8011.txt- operation [PWG5100.11] is the safe replacement for this operation and
../data/rfc/rfc8011.txt- makes a copy of the Job, assigns a new "job-uri" and "job-id" to the
../data/rfc/rfc8011.txt- copy, and resets the Job progress attributes in the new copy only.
../data/rfc/rfc8011.txt-
../data/rfc/rfc8011.txt- The Restart-Job operation moves the Job to the 'pending' or
--
../data/rfc/rfc8011.txt- o Obsoleted all attributes and values defined in RFC 3381, as they
../data/rfc/rfc8011.txt- do not interact well with the "finishings" attribute and have
../data/rfc/rfc8011.txt- never been widely implemented.
../data/rfc/rfc8011.txt-
../data/rfc/rfc8011.txt- o Deprecated the Purge-Jobs and Restart-Job operations, which
../data/rfc/rfc8011.txt: destroy accounting information.
../data/rfc/rfc8011.txt-
../data/rfc/rfc8011.txt-
../data/rfc/rfc8011.txt-
../data/rfc/rfc8011.txt-Sweet & McDonald Standards Track [Page 187]
../data/rfc/rfc8011.txt-
--
../data/rfc/rfc7337.txt-13.2. Informative References
../data/rfc/rfc7337.txt-
../data/rfc/rfc7337.txt- [AAA-REQS]
../data/rfc/rfc7337.txt- Gilletti, D., Nair, R., Scharber, J., and J. Guha,
../data/rfc/rfc7337.txt- "Content Internetworking (CDI) Authentication,
../data/rfc/rfc7337.txt: Authorization, and Accounting Requirements", Work in
../data/rfc/rfc7337.txt- Progress, June 2001.
../data/rfc/rfc7337.txt-
../data/rfc/rfc7337.txt- [ATIS-0800042]
../data/rfc/rfc7337.txt- ATIS, "ATIS IPTV Content on Demand Service", ATIS-0800042
../data/rfc/rfc7337.txt- v002, September 2011, <https://www.atis.org/docstore/
--
../data/rfc/rfc8415.txt- The information contained in the data area of this option is
../data/rfc/rfc8415.txt- contained in one or more opaque fields that represent the user class
../data/rfc/rfc8415.txt- or classes of which the client is a member. A server selects
../data/rfc/rfc8415.txt- configuration information for the client based on the classes
../data/rfc/rfc8415.txt- identified in this option. For example, the User Class option can be
../data/rfc/rfc8415.txt: used to configure all clients of people in the accounting department
../data/rfc/rfc8415.txt- with a different printer than clients of people in the marketing
../data/rfc/rfc8415.txt- department. The user class information carried in this option MUST
../data/rfc/rfc8415.txt- be configurable on the client.
../data/rfc/rfc8415.txt-
../data/rfc/rfc8415.txt- The data area of the User Class option MUST contain one or more
--
../data/rfc/rfc454.txt- normally be the first command transmitted by the user after the
../data/rfc/rfc454.txt- TELNET connections are made (some servers may require this).
../data/rfc/rfc454.txt- Additional identification information in the form of a password
../data/rfc/rfc454.txt- and/or an account command may also be required by some servers.
../data/rfc/rfc454.txt- Servers may allow a new USER command to be entered at any point in
../data/rfc/rfc454.txt: order to change the accounting information. All parameters are
../data/rfc/rfc454.txt- unchanged and any file transfer in progress is completed under the
../data/rfc/rfc454.txt- old account.
../data/rfc/rfc454.txt-
../data/rfc/rfc454.txt- Password (PASS) - The argument field is an ASCII string identify-
../data/rfc/rfc454.txt- ing the user's password. This command must be immediatly preceded
--
../data/rfc/rfc7170.txt-
../data/rfc/rfc7170.txt- [RFC6677] defines EAP channel bindings to solve the "lying NAS" and
../data/rfc/rfc7170.txt- the "lying provider" problems, using a process in which the EAP peer
../data/rfc/rfc7170.txt- gives information about the characteristics of the service provided
../data/rfc/rfc7170.txt- by the authenticator to the Authentication, Authorization, and
../data/rfc/rfc7170.txt: Accounting (AAA) server protected within the EAP method. This allows
../data/rfc/rfc7170.txt- the server to verify the authenticator is providing information to
../data/rfc/rfc7170.txt-
../data/rfc/rfc7170.txt-
../data/rfc/rfc7170.txt-
../data/rfc/rfc7170.txt-
--
../data/rfc/rfc7170.txt-
../data/rfc/rfc7170.txt- [RFC4945] Korver, B., "The Internet IP Security PKI Profile of IKEv1
../data/rfc/rfc7170.txt- /ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007.
../data/rfc/rfc7170.txt-
../data/rfc/rfc7170.txt- [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
../data/rfc/rfc7170.txt: Authorization, and Accounting (AAA) Key Management", BCP
../data/rfc/rfc7170.txt- 132, RFC 4962, July 2007.
../data/rfc/rfc7170.txt-
../data/rfc/rfc7170.txt- [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
../data/rfc/rfc7170.txt- Authentication Protocol (EAP) Key Management Framework",
../data/rfc/rfc7170.txt- RFC 5247, August 2008.
--
../data/rfc/rfc8241.txt- the I2RS architecture [RFC7921].
../data/rfc/rfc8241.txt-
../data/rfc/rfc8241.txt- I2RS reuses the secure transport protocols (TLS, SSH, DTLS) that
../data/rfc/rfc8241.txt- support encryption, message integrity, peer authentication, and key
../data/rfc/rfc8241.txt- distribution protocols. Optionally, implementers may utilize
../data/rfc/rfc8241.txt: Authentication, Authorization, and Accounting (AAA) protocols (Radius
../data/rfc/rfc8241.txt- over TLS or Diameter over TLS) to securely distribute identity
../data/rfc/rfc8241.txt- information.
../data/rfc/rfc8241.txt-
../data/rfc/rfc8241.txt- Section 2 highlights some of the terminology and concepts that the
../data/rfc/rfc8241.txt- reader is required to be familiar with.
--
../data/rfc/rfc8313.txt- 4.3.2. Inter-domain Authentication Guidelines .............28
../data/rfc/rfc8313.txt- 4.3.3. Log-Management Guidelines ..........................28
../data/rfc/rfc8313.txt- 4.4. Operations - Service Performance and Monitoring
../data/rfc/rfc8313.txt- Guidelines ................................................30
../data/rfc/rfc8313.txt- 4.5. Client Reliability Models / Service Assurance Guidelines ..32
../data/rfc/rfc8313.txt: 4.6. Application Accounting Guidelines .........................32
../data/rfc/rfc8313.txt- 5. Troubleshooting and Diagnostics ................................32
../data/rfc/rfc8313.txt- 6. Security Considerations ........................................33
../data/rfc/rfc8313.txt- 6.1. DoS Attacks (against State and Bandwidth) .................33
../data/rfc/rfc8313.txt- 6.2. Content Security ..........................................35
../data/rfc/rfc8313.txt- 6.3. Peering Encryption ........................................37
--
../data/rfc/rfc8313.txt-4.3.3. Log-Management Guidelines
../data/rfc/rfc8313.txt-
../data/rfc/rfc8313.txt- Successful delivery (in terms of user experience) of applications or
../data/rfc/rfc8313.txt- content via multicast between pairs of interconnecting ADs can be
../data/rfc/rfc8313.txt- improved through the ability to exchange appropriate logs for various
../data/rfc/rfc8313.txt: workflows -- troubleshooting, accounting and billing, optimization of
../data/rfc/rfc8313.txt- traffic and content transmission, optimization of content and
../data/rfc/rfc8313.txt- application development, and so on.
../data/rfc/rfc8313.txt-
../data/rfc/rfc8313.txt- Specifically, AD-1 take over primary responsibility for customer
../data/rfc/rfc8313.txt- experience on behalf of the content source, with support from AD-2 as
--
../data/rfc/rfc8313.txt- multicast application source providers.
../data/rfc/rfc8313.txt-
../data/rfc/rfc8313.txt- Network reliability can also be enhanced by the two ADs if they
../data/rfc/rfc8313.txt- provision alternate delivery mechanisms via unicast means.
../data/rfc/rfc8313.txt-
../data/rfc/rfc8313.txt:4.6. Application Accounting Guidelines
../data/rfc/rfc8313.txt-
../data/rfc/rfc8313.txt: Application-level accounting needs to be handled differently in the
../data/rfc/rfc8313.txt- application than in IP unicast, because the source side does not
../data/rfc/rfc8313.txt- directly deliver packets to individual receivers. Instead, this
../data/rfc/rfc8313.txt- needs to be signaled back by the receiver to the source.
../data/rfc/rfc8313.txt-
../data/rfc/rfc8313.txt- For network transport diagnostics, AD-1 and AD-2 should have
../data/rfc/rfc8313.txt: mechanisms in place to ensure proper accounting for the volume of
../data/rfc/rfc8313.txt- bytes delivered through the peering point and, separately, the number
../data/rfc/rfc8313.txt- of bytes delivered to EUs.
../data/rfc/rfc8313.txt-
../data/rfc/rfc8313.txt-5. Troubleshooting and Diagnostics
../data/rfc/rfc8313.txt-
--
../data/rfc/rfc8313.txt- information, as it provides operational insight into the originating
../data/rfc/rfc8313.txt- AD but also contains sensitive user data.
../data/rfc/rfc8313.txt-
../data/rfc/rfc8313.txt- Sensitive user data exported from AD-2 to AD-1 as part of logs could
../data/rfc/rfc8313.txt- be as much as the equivalent of 5-tuple unicast traffic flow
../data/rfc/rfc8313.txt: accounting (but not more, e.g., no application-level information).
../data/rfc/rfc8313.txt- As mentioned in Section 7, in unicast, AD-1 could capture these
../data/rfc/rfc8313.txt- traffic statistics itself because this is all about traffic flows
../data/rfc/rfc8313.txt- (originated by AD-1) to EU receivers in AD-2, and operationally
../data/rfc/rfc8313.txt- passing it from AD-2 to AD-1 may be necessary when IP multicast is
../data/rfc/rfc8313.txt- used because of the replication taking place in AD-2.
--
../data/rfc/rfc8170.txt- other entities also transition. Unfortunately, in such cases,
../data/rfc/rfc8170.txt- the natural incentive is often to delay transitioning.
../data/rfc/rfc8170.txt-
../data/rfc/rfc8170.txt- 3. Total Cost: It is important to consider costs that go beyond the
../data/rfc/rfc8170.txt- core hardware and software, such as operational tools and
../data/rfc/rfc8170.txt: processes, personnel training, business model (accounting/
../data/rfc/rfc8170.txt- billing) dependencies, and legal (regulation, patents, etc.)
../data/rfc/rfc8170.txt- costs.
../data/rfc/rfc8170.txt-
../data/rfc/rfc8170.txt- 4. Extensibility: Design for extensibility [RFC6709] so that things
../data/rfc/rfc8170.txt- can be fixed up later.
--
../data/rfc/rfc8170.txt- A transition plan should explain the incentives to each involved
../data/rfc/rfc8170.txt- entity to support the transition. Note here that many entities other
../data/rfc/rfc8170.txt- than the endpoint applications and their users may be affected, and
../data/rfc/rfc8170.txt- the barriers to transition may be non-technical as well as technical.
../data/rfc/rfc8170.txt- When considering these incentives, also consider network operations
../data/rfc/rfc8170.txt: tools, practices and processes, personnel training, accounting and
../data/rfc/rfc8170.txt- billing dependencies, and legal and regulatory incentives.
../data/rfc/rfc8170.txt-
../data/rfc/rfc8170.txt- If there is opposition to a particular new protocol (e.g., from
../data/rfc/rfc8170.txt- another standards organization, or a government, or some other
../data/rfc/rfc8170.txt- affected entity), various non-technical issues arise that should be
--
../data/rfc/rfc1340.txt- 64-149 Unassigned [JBP]
../data/rfc/rfc1340.txt- 150 Xerox NS IDP [133,XEROX]
../data/rfc/rfc1340.txt- 151 Unassigned [JBP]
../data/rfc/rfc1340.txt- 152 PARC Universal Protocol [8,XEROX]
../data/rfc/rfc1340.txt- 153 TIP Status Reporting [JGH]
../data/rfc/rfc1340.txt: 154 TIP Accounting [JGH]
../data/rfc/rfc1340.txt- 155 Internet Protocol [regular] [105,JBP]
../data/rfc/rfc1340.txt- 156-158 Internet Protocol [experimental] [105,JBP]
../data/rfc/rfc1340.txt- 159 Figleaf Link [JBW1]
../data/rfc/rfc1340.txt- 160 Blacker Local Network Protocol [DM28]
../data/rfc/rfc1340.txt- 161-194 Unassigned [JBP]
--
../data/rfc/rfc5290.txt- www.isoc.org/orgs/ac/cms/uploads/docs/2020_vision.pdf".
../data/rfc/rfc5290.txt-
../data/rfc/rfc5290.txt- [J88] V. Jacobson, Congestion Avoidance and Control, SIGCOMM '88,
../data/rfc/rfc5290.txt- August 1988.
../data/rfc/rfc5290.txt-
../data/rfc/rfc5290.txt: [K96] F. Kelly, Charging and Accounting for Bursty Connections,
../data/rfc/rfc5290.txt- In L. W. McKnight and J. P. Bailey, editors, Internet
../data/rfc/rfc5290.txt- Economics. MIT Press, 1997.
../data/rfc/rfc5290.txt-
../data/rfc/rfc5290.txt- [K97] F. Kelly, Charging and Rate Control for Elastic Traffic,
../data/rfc/rfc5290.txt- European Transactions on Telecommunications, 8:33--37,
--
../data/rfc/rfc3611.txt- instead. In addition, if it were found useful, they could be used
../data/rfc/rfc3611.txt- for applications limited to two participants.
../data/rfc/rfc3611.txt-
../data/rfc/rfc3611.txt- One use to which the packet-by-packet reports are not immediately
../data/rfc/rfc3611.txt- suited is for data packet acknowledgments as part of a packet
../data/rfc/rfc3611.txt: retransmission mechanism. The reason is that the packet accounting
../data/rfc/rfc3611.txt- technique suggested for these blocks differs from the packet
../data/rfc/rfc3611.txt: accounting normally employed by RTP. In order to favor measurement
../data/rfc/rfc3611.txt-
../data/rfc/rfc3611.txt-
../data/rfc/rfc3611.txt-
../data/rfc/rfc3611.txt-Friedman, et al. Standards Track [Page 5]
../data/rfc/rfc3611.txt-
--
../data/rfc/rfc3611.txt-
../data/rfc/rfc3611.txt- applications, an effort is made to interpret as little as possible at
../data/rfc/rfc3611.txt- the data receiver, and leave the interpretation as much as possible
../data/rfc/rfc3611.txt- to participants that receive the report blocks. Thus, for example, a
../data/rfc/rfc3611.txt- packet with an anomalous SSRC ID or an anomalous sequence number
../data/rfc/rfc3611.txt: might be excluded by normal RTP accounting, but would be reported
../data/rfc/rfc3611.txt- upon for network monitoring purposes.
../data/rfc/rfc3611.txt-
../data/rfc/rfc3611.txt- The Statistics Summary Report Block (Section 4.6) has also been
../data/rfc/rfc3611.txt- defined with network monitoring in mind. This block type can be used
../data/rfc/rfc3611.txt- equally well for reporting on unicast and multicast packet reception.
--
../data/rfc/rfc3611.txt-Friedman, et al. Standards Track [Page 9]
../data/rfc/rfc3611.txt-
../data/rfc/rfc3611.txt-RFC 3611 RTCP XR November 2003
../data/rfc/rfc3611.txt-
../data/rfc/rfc3611.txt-
../data/rfc/rfc3611.txt: accounting for Loss RLE Report Blocks will differ from the accounting
../data/rfc/rfc3611.txt- for the generation of the SR and RR packets described in the RTP
../data/rfc/rfc3611.txt: specification [9] in the following two areas: per-sender accounting
../data/rfc/rfc3611.txt: and per-packet accounting.
../data/rfc/rfc3611.txt-
../data/rfc/rfc3611.txt: In its per-sender accounting, an RTP session participant SHOULD NOT
../data/rfc/rfc3611.txt- make the receipt of a threshold minimum number of RTP packets a
../data/rfc/rfc3611.txt- condition for reporting upon the sender of those packets. This
../data/rfc/rfc3611.txt: accounting technique differs from the technique described in Section
../data/rfc/rfc3611.txt- 6.2.1 and Appendix A.1 of the RTP specification that allows a
../data/rfc/rfc3611.txt- threshold to determine whether a sender is considered valid.
../data/rfc/rfc3611.txt-
../data/rfc/rfc3611.txt: In its per-packet accounting, an RTP session participant SHOULD treat
../data/rfc/rfc3611.txt: all sequence numbers as valid. This accounting technique differs
../data/rfc/rfc3611.txt- from the technique described in Appendix A.1 of the RTP specification
../data/rfc/rfc3611.txt- that suggests ruling a sequence number valid or invalid on the basis
../data/rfc/rfc3611.txt- of its contiguity with the sequence numbers of previously received
../data/rfc/rfc3611.txt- packets.
../data/rfc/rfc3611.txt-
--
../data/rfc/rfc3611.txt- for example, of excluding the stray old packet from an unrelated
../data/rfc/rfc3611.txt- session from having an effect upon the calculation of the RTCP
../data/rfc/rfc3611.txt- transmission interval. The presence of stray packets might, on the
../data/rfc/rfc3611.txt- other hand, be of interest to a network monitoring application.
../data/rfc/rfc3611.txt-
../data/rfc/rfc3611.txt: One accounting interpretation that is still necessary is for a
../data/rfc/rfc3611.txt- participant to decide whether the 16 bit sequence number has rolled
../data/rfc/rfc3611.txt- over. Under ordinary circumstances this is not a difficult task.
../data/rfc/rfc3611.txt- For example, if packet number 65,535 (the highest possible sequence
../data/rfc/rfc3611.txt- number) is followed shortly by packet number 0, it is reasonable to
../data/rfc/rfc3611.txt- assume that there has been a rollover. However, it is possible that
../data/rfc/rfc3611.txt- the packet is an earlier one (from 65,535 packets earlier). It is
../data/rfc/rfc3611.txt- also possible that the sequence numbers have rolled over multiple
../data/rfc/rfc3611.txt- times, either forward or backward. The interpretation becomes more
../data/rfc/rfc3611.txt- difficult when there are large gaps between the sequence numbers,
../data/rfc/rfc3611.txt: even accounting for rollover, and when there are long intervals
../data/rfc/rfc3611.txt- between received packets.
../data/rfc/rfc3611.txt-
../data/rfc/rfc3611.txt: The per-packet accounting technique mandated here is for a
../data/rfc/rfc3611.txt- participant to keep track of the sequence number of the packet most
../data/rfc/rfc3611.txt- recently received from a sender. For the next packet that arrives
../data/rfc/rfc3611.txt- from that sender, the sequence number MUST be judged to fall no more
../data/rfc/rfc3611.txt- than 32,768 packets ahead or behind the most recent one, whichever
../data/rfc/rfc3611.txt- choice places it closer. In the event that both choices are equally
--
../data/rfc/rfc3611.txt-
../data/rfc/rfc3611.txt-A.1. Sequence Number Interpretation
../data/rfc/rfc3611.txt-
../data/rfc/rfc3611.txt- This is the algorithm suggested by Section 4.1 for keeping track of
../data/rfc/rfc3611.txt- the sequence numbers from a given sender. It implements the
../data/rfc/rfc3611.txt: accounting practice required for the generation of Loss RLE Report
../data/rfc/rfc3611.txt- Blocks.
../data/rfc/rfc3611.txt-
../data/rfc/rfc3611.txt- This algorithm keeps track of 16 bit sequence numbers by translating
../data/rfc/rfc3611.txt- them into a 32 bit sequence number space. The first packet received
../data/rfc/rfc3611.txt- from a source is considered to have arrived roughly in the middle of
--
../data/rfc/rfc6120.txt- secure than TLS plus SASL PLAIN), e.g., because the XMPP service
../data/rfc/rfc6120.txt- depends for authentication purposes on a database or directory
../data/rfc/rfc6120.txt- that is not under the control of the XMPP administrators, such as
../data/rfc/rfc6120.txt- Pluggable Authentication Modules (PAM), an Lightweight Directory
../data/rfc/rfc6120.txt- Access Protocol (LDAP) directory [LDAP], or an Authentication,
../data/rfc/rfc6120.txt: Authorization, and Accounting (AAA) key management protocol (for
../data/rfc/rfc6120.txt- guidance, refer to [AAA]). However, offering TLS plus SASL PLAIN
../data/rfc/rfc6120.txt- even when the server supports more secure alternatives might be
../data/rfc/rfc6120.txt- appropriate if the server needs to enable interoperability with an
../data/rfc/rfc6120.txt- installed base of clients that do not yet support SCRAM or other
../data/rfc/rfc6120.txt- alternatives that are more secure than TLS plus SASL PLAIN.
--
../data/rfc/rfc6120.txt- RFC 6121, March 2011.
../data/rfc/rfc6120.txt-
../data/rfc/rfc6120.txt-16.2. Informative References
../data/rfc/rfc6120.txt-
../data/rfc/rfc6120.txt- [AAA] Housley, R. and B. Aboba, "Guidance for
../data/rfc/rfc6120.txt: Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc6120.txt- Key Management", BCP 132, RFC 4962, July 2007.
../data/rfc/rfc6120.txt-
../data/rfc/rfc6120.txt- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
../data/rfc/rfc6120.txt- Specifications: ABNF", STD 68, RFC 5234,
../data/rfc/rfc6120.txt- January 2008.
--
../data/rfc/rfc147.txt-
../data/rfc/rfc147.txt- [Page 2]
../data/rfc/rfc147.txt-
../data/rfc/rfc147.txt-Network Socket Committee and Network Community 7 May 1971
../data/rfc/rfc147.txt-
../data/rfc/rfc147.txt:The definition of a socket is also related to the accounting procedures
../data/rfc/rfc147.txt-followed for network usage. Network Control Programs (NCPs) should log
../data/rfc/rfc147.txt-each connection made and record the time the connection was made, the time
../data/rfc/rfc147.txt-the connection was closed, the number of messages and number of bits
../data/rfc/rfc147.txt-transmitted over the connection, the sending and receiving hosts, and the
../data/rfc/rfc147.txt-sockets at the sending host and receiving host which participated in the
--
../data/rfc/rfc147.txt-The sockets used for facilities following a common network protocol, such
../data/rfc/rfc147.txt-as the ICP, should also follow this socket definition. Thus the logger
../data/rfc/rfc147.txt-socket at the Lincoln Laboratory 360/67 would be, and is, x'0A0000 01, ',
../data/rfc/rfc147.txt-i.e. home 10, user 0, and tag 1.
../data/rfc/rfc147.txt-
../data/rfc/rfc147.txt:This procedure for defining sockets enables an accounting procedure for
../data/rfc/rfc147.txt-identifying users of network facilities and for measuring network usage.
../data/rfc/rfc147.txt-
../data/rfc/rfc147.txt- [ This RFC was put into machine readable form for entry ]
../data/rfc/rfc147.txt- [ into the online RFC archives by BBN Corp. under the ]
../data/rfc/rfc147.txt- [ direction of Alex McKenzie. 12/96 ]
--
../data/rfc/rfc8049.txt- o Ellipsis ("...") stands for contents of subtrees that are not
../data/rfc/rfc8049.txt- shown.
../data/rfc/rfc8049.txt-
../data/rfc/rfc8049.txt-2. Acronyms
../data/rfc/rfc8049.txt-
../data/rfc/rfc8049.txt: AAA: Authentication, Authorization, and Accounting.
../data/rfc/rfc8049.txt-
../data/rfc/rfc8049.txt- ACL: Access Control List.
../data/rfc/rfc8049.txt-
../data/rfc/rfc8049.txt- ADSL: Asymmetric DSL.
../data/rfc/rfc8049.txt-
--
../data/rfc/rfc2513.txt- Cisco Systems, Inc.
../data/rfc/rfc2513.txt- February 1999
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- Managed Objects for Controlling the Collection
../data/rfc/rfc2513.txt: and Storage of Accounting Information for
../data/rfc/rfc2513.txt- Connection-Oriented Networks
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-Status of this Memo
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- This document specifies an Internet standards track protocol for the
--
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- 1 Introduction .................................................... 2
../data/rfc/rfc2513.txt- 2 The SNMP Network Management Framework ........................... 2
../data/rfc/rfc2513.txt- 3 Overview ........................................................ 3
../data/rfc/rfc2513.txt- 3.1 Operational Model ............................................. 3
../data/rfc/rfc2513.txt: 3.2 Selection of Accounting Data .................................. 5
../data/rfc/rfc2513.txt- 3.3 Format of Collection File ..................................... 6
../data/rfc/rfc2513.txt- 4 Definitions ..................................................... 9
../data/rfc/rfc2513.txt- 5 Acknowledgements ................................................25
../data/rfc/rfc2513.txt- 6 References ......................................................25
../data/rfc/rfc2513.txt- 7 Security Considerations .........................................27
--
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-McCloghrie, et. al. Standards Track [Page 1]
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:RFC 2513 Connection-Oriented Accounting MIB February 1999
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-1. Introduction
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- This memo defines a portion of the Management Information Base (MIB)
../data/rfc/rfc2513.txt- for use with network management protocols in the Internet community.
../data/rfc/rfc2513.txt- In particular, it describes managed objects used for controlling the
../data/rfc/rfc2513.txt: collection and storage of accounting information for connection-
../data/rfc/rfc2513.txt: oriented networks such as ATM. The accounting data is collected into
../data/rfc/rfc2513.txt- files for later retrieval via a file transfer protocol. For
../data/rfc/rfc2513.txt- information on data which can be collected for ATM networks, see
../data/rfc/rfc2513.txt- [19].
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-2. The SNMP Network Management Framework
--
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-McCloghrie, et. al. Standards Track [Page 2]
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:RFC 2513 Connection-Oriented Accounting MIB February 1999
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- This memo specifies a MIB module that is compliant to the SMIv2. A
../data/rfc/rfc2513.txt- MIB conforming to the SMIv1 can be produced through the appropriate
../data/rfc/rfc2513.txt- translations. The resulting translated MIB must be semantically
--
../data/rfc/rfc2513.txt- semantics of the MIB.
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-3. Overview
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- In some connection-oriented network environments, there is a need for
../data/rfc/rfc2513.txt: the network administrator to be able to collect accounting data on
../data/rfc/rfc2513.txt- the usage of bandwidth/resources by connections (e.g., ATM
../data/rfc/rfc2513.txt- connections) within the network. Data collection should be available
../data/rfc/rfc2513.txt- for switched virtual connections (SVCs and SVPs), and permanent
../data/rfc/rfc2513.txt- virtual connections (PVCs and PVPs), including soft-permanent virtual
../data/rfc/rfc2513.txt- connections (SPVCCs and SPVPCs). This need exists for ATM networks,
../data/rfc/rfc2513.txt- and may well exist for other connection-oriented networks, such as
../data/rfc/rfc2513.txt- Frame Relay.
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt: The potential quantity of such accounting information is such that it
../data/rfc/rfc2513.txt- is not, in general, feasible to retrieve the information via SNMP. A
../data/rfc/rfc2513.txt: better method is to store the collected accounting information in a
../data/rfc/rfc2513.txt- file which can be subsequently retrieved via a file transfer
../data/rfc/rfc2513.txt- protocol.
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- It is, however, appropriate to provide management control of the
../data/rfc/rfc2513.txt: selection and collection of such accounting data via SNMP. This memo
../data/rfc/rfc2513.txt- describes a MIB module which provides such control in a manner
../data/rfc/rfc2513.txt- independent of the type of network. One or more other documents
../data/rfc/rfc2513.txt: provide definitions of particular items of accounting data which can
../data/rfc/rfc2513.txt- be selected; for example, a particular set of data items which can be
../data/rfc/rfc2513.txt- collected for ATM networks is specified in [19].
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-3.1. Operational Model
../data/rfc/rfc2513.txt-
--
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-McCloghrie, et. al. Standards Track [Page 3]
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:RFC 2513 Connection-Oriented Accounting MIB February 1999
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- After this operation, the data in the old file is available for
../data/rfc/rfc2513.txt- retrieval via file transfer.
../data/rfc/rfc2513.txt-
--
../data/rfc/rfc2513.txt- of the file currently being collected exceeds a threshold percentage
../data/rfc/rfc2513.txt- of that maximum size, an SNMP notification (e.g., a trap) can be
../data/rfc/rfc2513.txt- optionally generated. An SNMP notification might also be generated
../data/rfc/rfc2513.txt- if the file reaches its maximum size.
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt: The accounting data collected for each connection consists of a set
../data/rfc/rfc2513.txt- of objects and their values. The set of objects and their values are
../data/rfc/rfc2513.txt- collected on one or more of the following occasions:
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- (1) on the release (termination) of a connection optionally
../data/rfc/rfc2513.txt- including failed connection attempts;
--
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-McCloghrie, et. al. Standards Track [Page 4]
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:RFC 2513 Connection-Oriented Accounting MIB February 1999
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- within the required time frame.
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- (2) agent automatically swaps to new file:
--
../data/rfc/rfc2513.txt- before or immediately after storing the whole of the current
../data/rfc/rfc2513.txt- connection record into the file. The former causes the file to be
../data/rfc/rfc2513.txt- just less than its maximum size, and the latter causes the file to be
../data/rfc/rfc2513.txt- just greater than its maximum size.
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:3.2. Selection of Accounting Data
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt: The items of accounting data to be collected are specified as a set
../data/rfc/rfc2513.txt- of objects. Which objects are contained in such a set is selectable
../data/rfc/rfc2513.txt- by an administrator through the specification of one or more
../data/rfc/rfc2513.txt- (subtree, list) tuples, where the set of objects to be collected is
../data/rfc/rfc2513.txt- the union of the subsets specified by each tuple:
../data/rfc/rfc2513.txt-
--
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-McCloghrie, et. al. Standards Track [Page 5]
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:RFC 2513 Connection-Oriented Accounting MIB February 1999
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- object in the set).
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- The number of tuples supported by a particular switch is an
--
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- A collection file generated by this process contains the values of
../data/rfc/rfc2513.txt- MIB objects defined using the SMIv2. The standard way to encode the
../data/rfc/rfc2513.txt- values of SNMP MIB objects in a device-independent manner is through
../data/rfc/rfc2513.txt- the use of ASN.1's Basic Encoding Rules (BER) [18]. Thus, the
../data/rfc/rfc2513.txt: standard format of an accounting file is defined here using the same
../data/rfc/rfc2513.txt- adapted subset of ASN.1 [17] as the SMIv2.
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- The file consists of a set of header information followed by a
../data/rfc/rfc2513.txt- sequence of zero or more collection records. The header information
../data/rfc/rfc2513.txt- identifies (via sysName [16]) the switch which collected the data,
--
../data/rfc/rfc2513.txt- identified tuple, in the same order as the tuples are identified in
../data/rfc/rfc2513.txt- the header information. For each tuple, the sequence of values are
../data/rfc/rfc2513.txt- in ascending order of the sub-identifier which identifies them within
../data/rfc/rfc2513.txt- the subtree.
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt: Formally, an accounting file is an ASN.1 value with the following
../data/rfc/rfc2513.txt- syntax:
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-File ::=
../data/rfc/rfc2513.txt- [1]
../data/rfc/rfc2513.txt- IMPLICIT SEQUENCE {
--
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-McCloghrie, et. al. Standards Track [Page 6]
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:RFC 2513 Connection-Oriented Accounting MIB February 1999
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- DateAndTime,
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- SEQUENCE OF { -- sequence of (subtree, list) tuples
--
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- (5) ObjectSyntax is defined by the SMIv2 [5].
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- (6) One particular category of object values deserves special
../data/rfc/rfc2513.txt- attention: an object defined to hold the checksum value of an
../data/rfc/rfc2513.txt: accounting record (e.g., atmAcctngRecordCrc16, defined in [19]).
../data/rfc/rfc2513.txt- An object in this category will generally have a SYNTAX of a
../data/rfc/rfc2513.txt- fixed-length OCTET STRING, and have its value initialized to the
../data/rfc/rfc2513.txt: string of all zeros when composing the accounting record
../data/rfc/rfc2513.txt- containing it, with the location of these zeros being saved.
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-McCloghrie, et. al. Standards Track [Page 7]
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:RFC 2513 Connection-Oriented Accounting MIB February 1999
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- Once the record is generated, the checksum is calculated over
../data/rfc/rfc2513.txt- the whole connection record (including the starting SEQUENCE OF
../data/rfc/rfc2513.txt- and the trailing end-of-contents octets, if used), and then the
--
../data/rfc/rfc2513.txt- end-of-contents 00 00
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- contains two connection records, each containing one tuple listing
../data/rfc/rfc2513.txt- two (integer) data items in a (fictitious) subtree:
../data/rfc/rfc2513.txt- 1.3.6.1.3.127.1.1. Its header indicates it's for "switch-12", with
../data/rfc/rfc2513.txt: description "Accounting", and was collected at 16:05:00 on 20 July
../data/rfc/rfc2513.txt- 1996.
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- As well as the standard format defined above, the MIB allows other
../data/rfc/rfc2513.txt- enterprise-specific formats to be used.
../data/rfc/rfc2513.txt-
--
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-McCloghrie, et. al. Standards Track [Page 8]
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:RFC 2513 Connection-Oriented Accounting MIB February 1999
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-4. Definitions
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:ACCOUNTING-CONTROL-MIB DEFINITIONS ::= BEGIN
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-IMPORTS
../data/rfc/rfc2513.txt- MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
../data/rfc/rfc2513.txt- mib-2, Integer32 FROM SNMPv2-SMI
../data/rfc/rfc2513.txt- TEXTUAL-CONVENTION, RowStatus, TestAndIncr,
--
../data/rfc/rfc2513.txt- MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
../data/rfc/rfc2513.txt- FROM SNMPv2-CONF
../data/rfc/rfc2513.txt- ifIndex FROM IF-MIB;
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:accountingControlMIB MODULE-IDENTITY
../data/rfc/rfc2513.txt- LAST-UPDATED "9809281000Z"
../data/rfc/rfc2513.txt- ORGANIZATION "IETF AToM MIB Working Group"
../data/rfc/rfc2513.txt- CONTACT-INFO "Keith McCloghrie
../data/rfc/rfc2513.txt- Cisco Systems, Inc.
../data/rfc/rfc2513.txt- 170 West Tasman Drive,
../data/rfc/rfc2513.txt- San Jose CA 95134-1706.
../data/rfc/rfc2513.txt- Phone: +1 408 526 5260
../data/rfc/rfc2513.txt- Email: kzm@cisco.com"
../data/rfc/rfc2513.txt- DESCRIPTION
../data/rfc/rfc2513.txt- "The MIB module for managing the collection and storage of
../data/rfc/rfc2513.txt: accounting information for connections in a connection-
../data/rfc/rfc2513.txt- oriented network such as ATM."
../data/rfc/rfc2513.txt- ::= { mib-2 60 }
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:acctngMIBObjects OBJECT IDENTIFIER ::= { accountingControlMIB 1 }
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-acctngSelectionControl OBJECT IDENTIFIER ::= { acctngMIBObjects 1 }
../data/rfc/rfc2513.txt-acctngFileControl OBJECT IDENTIFIER ::= { acctngMIBObjects 2 }
../data/rfc/rfc2513.txt-acctngInterfaceControl OBJECT IDENTIFIER ::= { acctngMIBObjects 3 }
../data/rfc/rfc2513.txt-acctngTrapControl OBJECT IDENTIFIER ::= { acctngMIBObjects 4 }
--
../data/rfc/rfc2513.txt-DataCollectionSubtree ::= TEXTUAL-CONVENTION
../data/rfc/rfc2513.txt- STATUS current
../data/rfc/rfc2513.txt- DESCRIPTION
../data/rfc/rfc2513.txt- "The subtree component of a (subtree, list) tuple. Such a
../data/rfc/rfc2513.txt- (subtree, list) tuple defines a set of objects and their
../data/rfc/rfc2513.txt: values to be collected as accounting data for a connection.
../data/rfc/rfc2513.txt- The subtree specifies a single OBJECT IDENTIFIER value such
../data/rfc/rfc2513.txt- that each object in the set is named by the subtree value
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-McCloghrie, et. al. Standards Track [Page 9]
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:RFC 2513 Connection-Oriented Accounting MIB February 1999
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- appended with a single additional sub-identifier."
../data/rfc/rfc2513.txt- SYNTAX OBJECT IDENTIFIER
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-DataCollectionList ::= TEXTUAL-CONVENTION
../data/rfc/rfc2513.txt- STATUS current
../data/rfc/rfc2513.txt- DESCRIPTION
../data/rfc/rfc2513.txt- "The list component of a (subtree, list) tuple. Such a
../data/rfc/rfc2513.txt- (subtree, list) tuple defines a set of objects and their
../data/rfc/rfc2513.txt: values to be collected as accounting data for a connection.
../data/rfc/rfc2513.txt- The subtree specifies a single OBJECT IDENTIFIER value such
../data/rfc/rfc2513.txt- that each object in the set is named by the subtree value
../data/rfc/rfc2513.txt- appended with a single additional sub-identifier. The list
../data/rfc/rfc2513.txt- specifies a set of data items, where the presence of an item
../data/rfc/rfc2513.txt- in the list indicates that the item is (to be) present in
--
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-FileIndex ::= TEXTUAL-CONVENTION
../data/rfc/rfc2513.txt- STATUS current
../data/rfc/rfc2513.txt- DESCRIPTION
../data/rfc/rfc2513.txt- "An arbitrary integer value identifying a file into which
../data/rfc/rfc2513.txt: accounting data is being collected."
../data/rfc/rfc2513.txt- SYNTAX Integer32 (1..65535)
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:-- The Accounting Information Selection table
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-McCloghrie, et. al. Standards Track [Page 10]
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:RFC 2513 Connection-Oriented Accounting MIB February 1999
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-acctngSelectionTable OBJECT-TYPE
../data/rfc/rfc2513.txt- SYNTAX SEQUENCE OF AcctngSelectionEntry
../data/rfc/rfc2513.txt- MAX-ACCESS not-accessible
../data/rfc/rfc2513.txt- STATUS current
../data/rfc/rfc2513.txt- DESCRIPTION
../data/rfc/rfc2513.txt: "A list of accounting information selection entries.
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- Note that additions, modifications and deletions of entries
../data/rfc/rfc2513.txt- in this table can occur at any time, but such changes only
../data/rfc/rfc2513.txt- take effect on the next occasion when collection begins into
../data/rfc/rfc2513.txt- a new file. Thus, between modification and the next 'swap',
--
../data/rfc/rfc2513.txt- SYNTAX AcctngSelectionEntry
../data/rfc/rfc2513.txt- MAX-ACCESS not-accessible
../data/rfc/rfc2513.txt- STATUS current
../data/rfc/rfc2513.txt- DESCRIPTION
../data/rfc/rfc2513.txt- "An entry identifying an (subtree, list) tuple used to
../data/rfc/rfc2513.txt: select a set of accounting information which is to be
../data/rfc/rfc2513.txt- collected."
../data/rfc/rfc2513.txt- INDEX { acctngSelectionIndex }
../data/rfc/rfc2513.txt- ::= { acctngSelectionTable 1 }
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-AcctngSelectionEntry ::=
--
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-McCloghrie, et. al. Standards Track [Page 11]
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:RFC 2513 Connection-Oriented Accounting MIB February 1999
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-acctngSelectionSubtree OBJECT-TYPE
../data/rfc/rfc2513.txt- SYNTAX DataCollectionSubtree
../data/rfc/rfc2513.txt- MAX-ACCESS read-create
--
../data/rfc/rfc2513.txt-acctngSelectionFile OBJECT-TYPE
../data/rfc/rfc2513.txt- SYNTAX FileIndex
../data/rfc/rfc2513.txt- MAX-ACCESS read-create
../data/rfc/rfc2513.txt- STATUS current
../data/rfc/rfc2513.txt- DESCRIPTION
../data/rfc/rfc2513.txt: "An indication of the file into which the accounting
../data/rfc/rfc2513.txt- information identified by this entry is to be stored. If
../data/rfc/rfc2513.txt- there is no conceptual row in the acctngFileTable for which
../data/rfc/rfc2513.txt- the value of acctngFileIndex has the same value as this
../data/rfc/rfc2513.txt- object, then the information selected by this entry is not
../data/rfc/rfc2513.txt- collected."
--
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-McCloghrie, et. al. Standards Track [Page 12]
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:RFC 2513 Connection-Oriented Accounting MIB February 1999
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- information selected by this entry are to be collected."
../data/rfc/rfc2513.txt- DEFVAL { { svcIncoming, svcOutgoing,
../data/rfc/rfc2513.txt- svpIncoming, svpOutgoing } }
--
../data/rfc/rfc2513.txt- 'active'. However, such changes only take effect upon the
../data/rfc/rfc2513.txt- next occasion when collection begins into a new (version of
../data/rfc/rfc2513.txt- the) file."
../data/rfc/rfc2513.txt- ::= { acctngSelectionEntry 6 }
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:-- The Accounting File table
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-acctngFileTable OBJECT-TYPE
../data/rfc/rfc2513.txt- SYNTAX SEQUENCE OF AcctngFileEntry
../data/rfc/rfc2513.txt- MAX-ACCESS not-accessible
../data/rfc/rfc2513.txt- STATUS current
../data/rfc/rfc2513.txt- DESCRIPTION
../data/rfc/rfc2513.txt: "A list of files into which accounting information is to be
../data/rfc/rfc2513.txt- stored."
../data/rfc/rfc2513.txt- ::= { acctngFileControl 1 }
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-acctngFileEntry OBJECT-TYPE
../data/rfc/rfc2513.txt- SYNTAX AcctngFileEntry
--
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-McCloghrie, et. al. Standards Track [Page 13]
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:RFC 2513 Connection-Oriented Accounting MIB February 1999
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- STATUS current
../data/rfc/rfc2513.txt- DESCRIPTION
../data/rfc/rfc2513.txt: "An entry identifying a file into which accounting
../data/rfc/rfc2513.txt- information is to be collected."
../data/rfc/rfc2513.txt- INDEX { acctngFileIndex }
../data/rfc/rfc2513.txt- ::= { acctngFileTable 1 }
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-AcctngFileEntry ::=
--
../data/rfc/rfc2513.txt-acctngFileIndex OBJECT-TYPE
../data/rfc/rfc2513.txt- SYNTAX FileIndex
../data/rfc/rfc2513.txt- MAX-ACCESS not-accessible
../data/rfc/rfc2513.txt- STATUS current
../data/rfc/rfc2513.txt- DESCRIPTION
../data/rfc/rfc2513.txt: "A unique value identifying a file into which accounting
../data/rfc/rfc2513.txt- data is to be stored. This value is required to be the
../data/rfc/rfc2513.txt- permanent 'handle' for an entry in this table for as long as
../data/rfc/rfc2513.txt- that entry exists, including across restarts and power
../data/rfc/rfc2513.txt- outages."
../data/rfc/rfc2513.txt- ::= { acctngFileEntry 1 }
--
../data/rfc/rfc2513.txt-acctngFileName OBJECT-TYPE
../data/rfc/rfc2513.txt- SYNTAX DisplayString (SIZE(1..32))
../data/rfc/rfc2513.txt- MAX-ACCESS read-create
../data/rfc/rfc2513.txt- STATUS current
../data/rfc/rfc2513.txt- DESCRIPTION
../data/rfc/rfc2513.txt: "The name of the file into which accounting data is to be
../data/rfc/rfc2513.txt- stored. If files are named using suffixes, then the name of
../data/rfc/rfc2513.txt- the current file is the concatenation of acctngFileName and
../data/rfc/rfc2513.txt- acctngFileNameSuffix.
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- An agent will respond with an error (e.g., 'wrongValue') to
--
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-McCloghrie, et. al. Standards Track [Page 14]
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:RFC 2513 Connection-Oriented Accounting MIB February 1999
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- value of this object to the same value as already held by
../data/rfc/rfc2513.txt- another instance of acctngFileName. An agent will also
../data/rfc/rfc2513.txt- respond with an error (e.g., 'wrongValue') if the new value
--
../data/rfc/rfc2513.txt- SYNTAX DisplayString (SIZE(0..8))
../data/rfc/rfc2513.txt- MAX-ACCESS read-only
../data/rfc/rfc2513.txt- STATUS current
../data/rfc/rfc2513.txt- DESCRIPTION
../data/rfc/rfc2513.txt- "The suffix, if any, of the name of a file into which
../data/rfc/rfc2513.txt: accounting data is currently being stored. If suffixes are
../data/rfc/rfc2513.txt- not used, then the value of this object is the zero-length
../data/rfc/rfc2513.txt- string. Note that if a separator, such as a period, is used
../data/rfc/rfc2513.txt- in appending the suffix to the file name, then that
../data/rfc/rfc2513.txt- separator appears as the first character of this value."
../data/rfc/rfc2513.txt- ::= { acctngFileEntry 3 }
--
../data/rfc/rfc2513.txt-acctngFileDescription OBJECT-TYPE
../data/rfc/rfc2513.txt- SYNTAX DisplayString
../data/rfc/rfc2513.txt- MAX-ACCESS read-create
../data/rfc/rfc2513.txt- STATUS current
../data/rfc/rfc2513.txt- DESCRIPTION
../data/rfc/rfc2513.txt: "The textual description of the accounting data which will
../data/rfc/rfc2513.txt- be stored (on the next occasion) when header information is
../data/rfc/rfc2513.txt- stored in the file. The value of this object may be
../data/rfc/rfc2513.txt- modified at any time."
../data/rfc/rfc2513.txt- DEFVAL { "" }
../data/rfc/rfc2513.txt- ::= { acctngFileEntry 4 }
--
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-McCloghrie, et. al. Standards Track [Page 15]
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:RFC 2513 Connection-Oriented Accounting MIB February 1999
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- STATUS current
../data/rfc/rfc2513.txt- DESCRIPTION
../data/rfc/rfc2513.txt: "A control object for the collection of accounting data.
../data/rfc/rfc2513.txt- When read the value is either 'idle' or 'cmdInProgress'.
../data/rfc/rfc2513.txt- Writing a value is only allowed when the current value is
../data/rfc/rfc2513.txt- 'idle'. When a value is successfully written, the value
../data/rfc/rfc2513.txt- changes to 'cmdInProgress' until completion of the action,
../data/rfc/rfc2513.txt- at which time the value reverts to 'idle'. Actions are
--
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-McCloghrie, et. al. Standards Track [Page 16]
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:RFC 2513 Connection-Oriented Accounting MIB February 1999
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- STATUS current
../data/rfc/rfc2513.txt- DESCRIPTION
../data/rfc/rfc2513.txt- "The current size of the file into which data is currently
--
../data/rfc/rfc2513.txt-acctngFileFormat OBJECT-TYPE
../data/rfc/rfc2513.txt- SYNTAX INTEGER { other(1), ber(2) }
../data/rfc/rfc2513.txt- MAX-ACCESS read-create
../data/rfc/rfc2513.txt- STATUS current
../data/rfc/rfc2513.txt- DESCRIPTION
../data/rfc/rfc2513.txt: "An indication of the format in which the accounting data is
../data/rfc/rfc2513.txt- to be stored in the file. If the value is modified, the new
../data/rfc/rfc2513.txt- value takes effect after the next 'swap' to a new file. The
../data/rfc/rfc2513.txt- value ber(2) indicates the standard format."
../data/rfc/rfc2513.txt- DEFVAL { ber }
../data/rfc/rfc2513.txt- ::= { acctngFileEntry 8 }
--
../data/rfc/rfc2513.txt-acctngFileCollectMode OBJECT-TYPE
../data/rfc/rfc2513.txt- SYNTAX BITS { onRelease(0), periodically(1) }
../data/rfc/rfc2513.txt- MAX-ACCESS read-create
../data/rfc/rfc2513.txt- STATUS current
../data/rfc/rfc2513.txt- DESCRIPTION
../data/rfc/rfc2513.txt: "An indication of when accounting data is to be written into
../data/rfc/rfc2513.txt- this file. Note that in addition to the occasions indicated
../data/rfc/rfc2513.txt- by the value of this object, an agent always writes
../data/rfc/rfc2513.txt- information on appropriate connections to the file when the
../data/rfc/rfc2513.txt- corresponding instance of acctngFileCommand is set to
../data/rfc/rfc2513.txt- 'collectNow'.
--
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-McCloghrie, et. al. Standards Track [Page 17]
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:RFC 2513 Connection-Oriented Accounting MIB February 1999
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- for failed connection attempts when the value of the
../data/rfc/rfc2513.txt- corresponding instance of acctngFileCollectMode includes
../data/rfc/rfc2513.txt- 'onRelease'. The individual values have the following
--
../data/rfc/rfc2513.txt- UNITS "seconds"
../data/rfc/rfc2513.txt- MAX-ACCESS read-create
../data/rfc/rfc2513.txt- STATUS current
../data/rfc/rfc2513.txt- DESCRIPTION
../data/rfc/rfc2513.txt- "The number of seconds between the periodic collections of
../data/rfc/rfc2513.txt: accounting data when the value of the corresponding instance
../data/rfc/rfc2513.txt- of acctngFileCollectMode includes 'periodically'. Some
../data/rfc/rfc2513.txt- agents may impose restrictions on the range of this
../data/rfc/rfc2513.txt- interval. This value may be modified at any time."
../data/rfc/rfc2513.txt- DEFVAL { 3600 }
../data/rfc/rfc2513.txt- ::= { acctngFileEntry 11 }
--
../data/rfc/rfc2513.txt- periodic intervals and/or when acctngFileCommand is set to
../data/rfc/rfc2513.txt- 'collectNow'. The age of a connection is the elapsed time
../data/rfc/rfc2513.txt- since it was last installed.
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- When the periodic interval expires for a file or when
../data/rfc/rfc2513.txt: acctngFileCommand is set to 'collectNow', accounting data is
../data/rfc/rfc2513.txt- collected and stored in the file for each connection having
../data/rfc/rfc2513.txt- a type matching acctngSelectionType and whose age at that
../data/rfc/rfc2513.txt- time is greater than the value of acctngFileMinAge
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-McCloghrie, et. al. Standards Track [Page 18]
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:RFC 2513 Connection-Oriented Accounting MIB February 1999
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- associated with the file. This value may be modified at any
../data/rfc/rfc2513.txt- time."
../data/rfc/rfc2513.txt- DEFVAL { 3600 }
--
../data/rfc/rfc2513.txt- SYNTAX INTEGER { enabled(1), disabled(2) }
../data/rfc/rfc2513.txt- MAX-ACCESS read-write
../data/rfc/rfc2513.txt- STATUS current
../data/rfc/rfc2513.txt- DESCRIPTION
../data/rfc/rfc2513.txt- "A control object to indicate the administratively desired
../data/rfc/rfc2513.txt: state of the collection of accounting records across all
../data/rfc/rfc2513.txt- interfaces.
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- Modifying the value of acctngAdminStatus to 'disabled' does
../data/rfc/rfc2513.txt- not remove or change the current configuration as
../data/rfc/rfc2513.txt- represented by the active rows in the acctngSelectionTable,
--
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-McCloghrie, et. al. Standards Track [Page 19]
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:RFC 2513 Connection-Oriented Accounting MIB February 1999
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- "A status object to indicate the operational state of the
../data/rfc/rfc2513.txt: collection of accounting records across all interfaces.
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- When the value of acctngAdminStatus is modified to be
../data/rfc/rfc2513.txt- 'enabled', the value of this object will change to 'enabled'
../data/rfc/rfc2513.txt: providing it is possible to begin collecting accounting
../data/rfc/rfc2513.txt- records.
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- When the value of acctngAdminStatus is modified to be
../data/rfc/rfc2513.txt- 'disabled', the value of this object will change to
../data/rfc/rfc2513.txt: 'disabled' as soon as the collection of accounting records
../data/rfc/rfc2513.txt- has terminated."
../data/rfc/rfc2513.txt- ::= { acctngInterfaceControl 2 }
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-acctngProtection OBJECT-TYPE
../data/rfc/rfc2513.txt- SYNTAX TestAndIncr
--
../data/rfc/rfc2513.txt- "A control object to protect against duplication of control
../data/rfc/rfc2513.txt- commands. Over some transport/network protocols, it is
../data/rfc/rfc2513.txt- possible for SNMP messages to get duplicated. Such
../data/rfc/rfc2513.txt- duplication, if it occurred at just the wrong time could
../data/rfc/rfc2513.txt- cause serious disruption to the collection and retrieval of
../data/rfc/rfc2513.txt: accounting data, e.g., if a SNMP message setting
../data/rfc/rfc2513.txt- acctngFileCommand to 'swapToNewFile' were to be duplicated,
../data/rfc/rfc2513.txt: a whole file of accounting data could be lost.
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- To protect against such duplication, a management
../data/rfc/rfc2513.txt- application should retrieve the value of this object, and
../data/rfc/rfc2513.txt- include in the Set operation needing protection, a variable
../data/rfc/rfc2513.txt- binding which sets this object to the retrieved value."
--
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-McCloghrie, et. al. Standards Track [Page 20]
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:RFC 2513 Connection-Oriented Accounting MIB February 1999
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- current file as and when that file becomes full."
../data/rfc/rfc2513.txt- ::= { acctngInterfaceControl 4 }
../data/rfc/rfc2513.txt-
--
../data/rfc/rfc2513.txt-acctngInterfaceTable OBJECT-TYPE
../data/rfc/rfc2513.txt- SYNTAX SEQUENCE OF AcctngInterfaceEntry
../data/rfc/rfc2513.txt- MAX-ACCESS not-accessible
../data/rfc/rfc2513.txt- STATUS current
../data/rfc/rfc2513.txt- DESCRIPTION
../data/rfc/rfc2513.txt: "A table controlling the collection of accounting data on
../data/rfc/rfc2513.txt- specific interfaces of the switch."
../data/rfc/rfc2513.txt- ::= { acctngInterfaceControl 5 }
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-acctngInterfaceEntry OBJECT-TYPE
../data/rfc/rfc2513.txt- SYNTAX AcctngInterfaceEntry
../data/rfc/rfc2513.txt- MAX-ACCESS not-accessible
../data/rfc/rfc2513.txt- STATUS current
../data/rfc/rfc2513.txt- DESCRIPTION
../data/rfc/rfc2513.txt: "An entry which controls whether accounting data is to be
../data/rfc/rfc2513.txt- collected on an interface. The types of interfaces which
../data/rfc/rfc2513.txt- are represented in this table is implementation-specific."
../data/rfc/rfc2513.txt- INDEX { ifIndex }
../data/rfc/rfc2513.txt- ::= { acctngInterfaceTable 1 }
../data/rfc/rfc2513.txt-
--
../data/rfc/rfc2513.txt-acctngInterfaceEnable OBJECT-TYPE
../data/rfc/rfc2513.txt- SYNTAX TruthValue
../data/rfc/rfc2513.txt- MAX-ACCESS read-write
../data/rfc/rfc2513.txt- STATUS current
../data/rfc/rfc2513.txt- DESCRIPTION
../data/rfc/rfc2513.txt: "Indicates whether the collection of accounting data is
../data/rfc/rfc2513.txt- enabled on this interface."
../data/rfc/rfc2513.txt- ::= { acctngInterfaceEntry 1 }
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt--- Objects for controlling the use of Notifications
../data/rfc/rfc2513.txt-
--
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-McCloghrie, et. al. Standards Track [Page 21]
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:RFC 2513 Connection-Oriented Accounting MIB February 1999
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- full' trap is generated. The value of 0 indicates that no
../data/rfc/rfc2513.txt- 'nearly-full' trap is to be generated."
../data/rfc/rfc2513.txt- ::= { acctngTrapControl 1 }
--
../data/rfc/rfc2513.txt- acctngFileFull traps are enabled."
../data/rfc/rfc2513.txt- ::= { acctngTrapControl 2 }
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt--- notifications
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:acctngNotifications OBJECT IDENTIFIER ::= { accountingControlMIB 2 }
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-acctngNotifyPrefix OBJECT IDENTIFIER ::= { acctngNotifications 0 }
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-acctngFileNearlyFull NOTIFICATION-TYPE
--
../data/rfc/rfc2513.txt- acctngControlTrapThreshold,
../data/rfc/rfc2513.txt- acctngFileNameSuffix }
../data/rfc/rfc2513.txt- STATUS current
../data/rfc/rfc2513.txt- DESCRIPTION
../data/rfc/rfc2513.txt- "An indication that the size of the file into which
../data/rfc/rfc2513.txt: accounting information is currently being collected has
../data/rfc/rfc2513.txt- exceeded the threshold percentage of its maximum file size.
../data/rfc/rfc2513.txt- This notification is generated only at the time of the
../data/rfc/rfc2513.txt- transition from not-exceeding to exceeding."
../data/rfc/rfc2513.txt- ::= { acctngNotifyPrefix 1 }
../data/rfc/rfc2513.txt-
--
../data/rfc/rfc2513.txt- acctngFileMaximumSize,
../data/rfc/rfc2513.txt- acctngFileNameSuffix }
../data/rfc/rfc2513.txt- STATUS current
../data/rfc/rfc2513.txt- DESCRIPTION
../data/rfc/rfc2513.txt- "An indication that the size of the file into which
../data/rfc/rfc2513.txt: accounting information is currently being collected has
../data/rfc/rfc2513.txt- transistioned to its maximum file size. This notification
../data/rfc/rfc2513.txt- is generated (for all values of acctngAgentMode) at the time
../data/rfc/rfc2513.txt- of the transition from not-full to full. If acctngAgentMode
../data/rfc/rfc2513.txt- has the value 'swapOnCommand', it is also generated
../data/rfc/rfc2513.txt- periodically thereafter until such time as collection of
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-McCloghrie, et. al. Standards Track [Page 22]
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:RFC 2513 Connection-Oriented Accounting MIB February 1999
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- data is no longer inhibited by the file full condition."
../data/rfc/rfc2513.txt- ::= { acctngNotifyPrefix 2 }
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt--- conformance information
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:acctngConformance OBJECT IDENTIFIER ::= { accountingControlMIB 3 }
../data/rfc/rfc2513.txt-acctngGroups OBJECT IDENTIFIER ::= { acctngConformance 1 }
../data/rfc/rfc2513.txt-acctngCompliances OBJECT IDENTIFIER ::= { acctngConformance 2 }
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-acctngCompliance MODULE-COMPLIANCE
../data/rfc/rfc2513.txt- STATUS current
../data/rfc/rfc2513.txt- DESCRIPTION
../data/rfc/rfc2513.txt- "The compliance statement for switches which implement the
../data/rfc/rfc2513.txt: Accounting Control MIB."
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- MODULE -- this module
../data/rfc/rfc2513.txt- MANDATORY-GROUPS { acctngBasicGroup,
../data/rfc/rfc2513.txt- acctngNotificationsGroup }
../data/rfc/rfc2513.txt-
--
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-McCloghrie, et. al. Standards Track [Page 23]
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:RFC 2513 Connection-Oriented Accounting MIB February 1999
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- MIN-ACCESS read-only
../data/rfc/rfc2513.txt- DESCRIPTION "The minimal requirement is for collection on
../data/rfc/rfc2513.txt- connection release."
--
../data/rfc/rfc2513.txt- acctngControlTrapEnable
../data/rfc/rfc2513.txt- }
../data/rfc/rfc2513.txt- STATUS current
../data/rfc/rfc2513.txt- DESCRIPTION
../data/rfc/rfc2513.txt- "A collection of objects providing control of the basic
../data/rfc/rfc2513.txt: collection of accounting data for connection-oriented
../data/rfc/rfc2513.txt- networks."
../data/rfc/rfc2513.txt- ::= { acctngGroups 1 }
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-acctngNotificationsGroup NOTIFICATION-GROUP
../data/rfc/rfc2513.txt- NOTIFICATIONS { acctngFileNearlyFull, acctngFileFull }
--
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-McCloghrie, et. al. Standards Track [Page 24]
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:RFC 2513 Connection-Oriented Accounting MIB February 1999
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- "The notifications of events relating to controlling the
../data/rfc/rfc2513.txt: collection of accounting data."
../data/rfc/rfc2513.txt- ::= { acctngGroups 2 }
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-END
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-5. Acknowledgements
--
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-McCloghrie, et. al. Standards Track [Page 25]
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:RFC 2513 Connection-Oriented Accounting MIB February 1999
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message
../data/rfc/rfc2513.txt- Processing and Dispatching for the Simple Network Management
../data/rfc/rfc2513.txt- Protocol (SNMP)", RFC 2272, January 1998.
--
../data/rfc/rfc2513.txt- "Specification of Basic Encoding Rules for Abstract Syntax
../data/rfc/rfc2513.txt- Notation One (ASN.1)", International Organization for
../data/rfc/rfc2513.txt- Standardization, Internation Standard 8825, December 1987.
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- [19] McCloghrie, K., Heinanen, J., Greene, W. and A. Prasad,
../data/rfc/rfc2513.txt: "Accounting Information for ATM Networks", RFC 2512, February
../data/rfc/rfc2513.txt- 1999.
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- [20] Noto, M., Spiegel, E., and K. Tesink, "Definitions of Textual
../data/rfc/rfc2513.txt- Conventions and OBJECT-IDENTITIES for ATM Management", RFC 2514,
../data/rfc/rfc2513.txt- February 1999.
--
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-McCloghrie, et. al. Standards Track [Page 26]
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:RFC 2513 Connection-Oriented Accounting MIB February 1999
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-7. Security Considerations
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- The MIB defined in this memo controls and monitors the collection of
../data/rfc/rfc2513.txt: accounting data. Care should be taken to prohibit unauthorized
../data/rfc/rfc2513.txt- access to this control capability in order to prevent the disruption
../data/rfc/rfc2513.txt- of data collection, possibly with fraudulent intent. Example of such
../data/rfc/rfc2513.txt- disruption are disabling the collection of data, or causing the wrong
../data/rfc/rfc2513.txt- set of data items to be collected.
../data/rfc/rfc2513.txt-
--
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-McCloghrie, et. al. Standards Track [Page 27]
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:RFC 2513 Connection-Oriented Accounting MIB February 1999
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-9. Authors' Addresses
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- Keith McCloghrie
--
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-McCloghrie, et. al. Standards Track [Page 28]
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt:RFC 2513 Connection-Oriented Accounting MIB February 1999
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt-10. Full Copyright Statement
../data/rfc/rfc2513.txt-
../data/rfc/rfc2513.txt- Copyright (C) The Internet Society (1999). All Rights Reserved.
--
../data/rfc/rfc4838.txt-4.2. Custody Transfer State
../data/rfc/rfc4838.txt-
../data/rfc/rfc4838.txt- Custody transfer state includes information required to keep account
../data/rfc/rfc4838.txt- of bundles for which a node has taken custody, as well as the
../data/rfc/rfc4838.txt- protocol state related to transferring custody for one or more of
../data/rfc/rfc4838.txt: them. The accounting-related state is created when a bundle is
../data/rfc/rfc4838.txt- received. Custody transfer retransmission state is created when a
../data/rfc/rfc4838.txt- transfer of custody is initiated by forwarding a bundle with the
../data/rfc/rfc4838.txt- custody transfer requested delivery option specified. Retransmission
../data/rfc/rfc4838.txt: state and accounting state may be released upon receipt of one or
../data/rfc/rfc4838.txt- more Custody Transfer Succeeded signals, indicating custody has been
../data/rfc/rfc4838.txt- moved. In addition, the bundle's expiration time (possibly mitigated
../data/rfc/rfc4838.txt- by local policy) provides an upper bound on the time when this state
../data/rfc/rfc4838.txt- is purged from the system in the event that it is not purged
../data/rfc/rfc4838.txt- explicitly due to receipt of a signal.
--
../data/rfc/rfc5666.txt-
../data/rfc/rfc5666.txt-RFC 5666 RDMA Transport for RPC January 2010
../data/rfc/rfc5666.txt-
../data/rfc/rfc5666.txt-
../data/rfc/rfc5666.txt- account for its required Done messages to the server in its
../data/rfc/rfc5666.txt: accounting of available credits, and the server SHOULD replenish any
../data/rfc/rfc5666.txt- credit consumed by its use of such exchanges at its earliest
../data/rfc/rfc5666.txt- opportunity.
../data/rfc/rfc5666.txt-
../data/rfc/rfc5666.txt- Finally, it is possible to conceive of RPC exchanges that involve any
../data/rfc/rfc5666.txt- or all combinations of write chunks in the RPC call, read chunks in
--
../data/rfc/rfc7554.txt- RPL is able to quickly build up network routes, distribute routing
../data/rfc/rfc7554.txt- knowledge among nodes, and adapt to a changing topology. In a
../data/rfc/rfc7554.txt- typical setting, nodes are connected through multi-hop paths to a
../data/rfc/rfc7554.txt- small set of root devices, which are usually responsible for data
../data/rfc/rfc7554.txt- collection and coordination. For each of them, a Destination-
../data/rfc/rfc7554.txt: Oriented Directed Acyclic Graph (DODAG) is created by accounting for
../data/rfc/rfc7554.txt- link costs, node attributes/status information, and an Objective
../data/rfc/rfc7554.txt- Function, which maps the optimization requirements of the target
../data/rfc/rfc7554.txt- scenario.
../data/rfc/rfc7554.txt-
../data/rfc/rfc7554.txt- The topology is set up based on a Rank metric, which encodes the
--
../data/rfc/rfc7598.txt- address bits).
../data/rfc/rfc7598.txt-
../data/rfc/rfc7598.txt- The DHCPv6 options described here tie the provisioning parameters,
../data/rfc/rfc7598.txt- and hence the IPv4 service itself, to the End-user IPv6 prefix
../data/rfc/rfc7598.txt- lifetime. The validity of a Softwire46's IPv4 address, prefix, or
../data/rfc/rfc7598.txt: shared IPv4 address; port set; and any authorization and accounting
../data/rfc/rfc7598.txt- are tied to the lifetime of its associated End-user IPv6 prefix.
../data/rfc/rfc7598.txt-
../data/rfc/rfc7598.txt- To support more than one mechanism at a time and to allow for a
../data/rfc/rfc7598.txt- possibility of transition between them, the DHCPv6 Option Request
../data/rfc/rfc7598.txt- Option (ORO) [RFC3315] is used. Each mechanism has a corresponding
--
../data/rfc/rfc2588.txt- sections.
../data/rfc/rfc2588.txt-
../data/rfc/rfc2588.txt- Note that because a firewall is often a convenient place to
../data/rfc/rfc2588.txt- centralize the administration of the intranet, some firewalls might
../data/rfc/rfc2588.txt- also perform additional administrative functions - for example,
../data/rfc/rfc2588.txt: auditing, accounting, and resource monitoring. These additional
../data/rfc/rfc2588.txt- functions, however, are outside the scope of this document, because
../data/rfc/rfc2588.txt- they are not specifically *firewall*-related. They are equally
../data/rfc/rfc2588.txt- applicable to an administrative domain that is not firewalled.
../data/rfc/rfc2588.txt-
../data/rfc/rfc2588.txt-6. Supporting a Multicast Security Policy
--
../data/rfc/rfc585.txt- address system.
../data/rfc/rfc585.txt-
../data/rfc/rfc585.txt- d. (Discussion of the current work on the Mail Protocol indicated
../data/rfc/rfc585.txt- that some of these ideas are already being considered)
../data/rfc/rfc585.txt-
../data/rfc/rfc585.txt: 8. Uniform Accounting Procedures and Online Status of Accounts
../data/rfc/rfc585.txt-
../data/rfc/rfc585.txt- a. This topic was covered in detail by sections of the Resource
../data/rfc/rfc585.txt- Sharing Workshop. It is mentioned here only because it is a
../data/rfc/rfc585.txt- problem of real concern to users.
../data/rfc/rfc585.txt-
../data/rfc/rfc585.txt- 9. Trial Usage and Browsing
../data/rfc/rfc585.txt-
../data/rfc/rfc585.txt- a. Ideally, users should be allowed some `free' sampling of
../data/rfc/rfc585.txt- systems and features available at each site. Practically, this
../data/rfc/rfc585.txt: presents problems of space allocation, accounting, consulting,
../data/rfc/rfc585.txt- etc. Although none of these problems are easy to solve
../data/rfc/rfc585.txt- equitably, an attempt should still be made to provide some free
../data/rfc/rfc585.txt- usage to everyone.
../data/rfc/rfc585.txt- b. Several types of trial usage should be considered, such as for
../data/rfc/rfc585.txt- those who will make an immediate commitment and those who wish
--
../data/rfc/rfc3748.txt- authentication service to an authenticator. When used, this
../data/rfc/rfc3748.txt- server typically executes EAP methods for the authenticator. This
../data/rfc/rfc3748.txt- terminology is also used in [IEEE-802.1X].
../data/rfc/rfc3748.txt-
../data/rfc/rfc3748.txt- AAA
../data/rfc/rfc3748.txt: Authentication, Authorization, and Accounting. AAA protocols with
../data/rfc/rfc3748.txt- EAP support include RADIUS [RFC3579] and Diameter [DIAM-EAP]. In
../data/rfc/rfc3748.txt- this document, the terms "AAA server" and "backend authentication
../data/rfc/rfc3748.txt- server" are used interchangeably.
../data/rfc/rfc3748.txt-
../data/rfc/rfc3748.txt- Displayable Message
--
../data/rfc/rfc7561.txt- parameters between IEEE 802.11 and PMIPv6 QoS is described in
../data/rfc/rfc7561.txt- Section 4.
../data/rfc/rfc7561.txt-
../data/rfc/rfc7561.txt-1.1. Abbreviations
../data/rfc/rfc7561.txt-
../data/rfc/rfc7561.txt: AAA Authentication, Authorization, and Accounting
../data/rfc/rfc7561.txt- AARP Allocation and Retention Priority
../data/rfc/rfc7561.txt- AC Access Category
../data/rfc/rfc7561.txt- ADDTS ADD Traffic Stream
../data/rfc/rfc7561.txt- AIFS Arbitration Inter-Frame Space
../data/rfc/rfc7561.txt- ALG Application Layer Gateway
--
../data/rfc/rfc3439.txt- TCP good-put [ROMANOV] on ATM showed that large UBR buffers (larger
../data/rfc/rfc3439.txt- than one TCP window size) are required to achieve reasonable
../data/rfc/rfc3439.txt- performance, that packet discard mechanisms (such as Early Packet
../data/rfc/rfc3439.txt- Discard, or EPD) improve the effective usage of the bandwidth and
../data/rfc/rfc3439.txt- that more elaborate service and drop strategies than FIFO+EPD, such
../data/rfc/rfc3439.txt: as per VC queuing and accounting, might be required at the bottleneck
../data/rfc/rfc3439.txt- to ensure both high efficiency and fairness. Though all studies
../data/rfc/rfc3439.txt- clearly indicate that a buffer size not less than one TCP window size
../data/rfc/rfc3439.txt- is required, the amount of extra buffer required naturally depends on
../data/rfc/rfc3439.txt- the packet discard mechanism used and is still an open issue.
../data/rfc/rfc3439.txt-
--
../data/rfc/rfc100.txt-
../data/rfc/rfc100.txt- NWG/RFC #s: 76
../data/rfc/rfc100.txt-
../data/rfc/rfc100.txt- 76 describes the PDP-11 ARPA Network Terminal System implementation.
../data/rfc/rfc100.txt-
../data/rfc/rfc100.txt:H. ACCOUNTING
../data/rfc/rfc100.txt-
../data/rfc/rfc100.txt- To be published: B. Kahn, BBN, will generate an RFC discussing
../data/rfc/rfc100.txt: important considerations for an accounting mechanism.
../data/rfc/rfc100.txt-
../data/rfc/rfc100.txt- NWG.RFC #s: 77, 82
../data/rfc/rfc100.txt-
../data/rfc/rfc100.txt- This topic will be addressed by the long-range Host/Host protocol
../data/rfc/rfc100.txt- committee, set up at the Network meeting, University of Illinois,
../data/rfc/rfc100.txt- February 1971.
../data/rfc/rfc100.txt-
../data/rfc/rfc100.txt: 77 and 82 discuss the need for some network accounting scheme,
../data/rfc/rfc100.txt- primarily for sites classified as Service Centers rather than
../data/rfc/rfc100.txt- Research Centers.
../data/rfc/rfc100.txt-
../data/rfc/rfc100.txt-
../data/rfc/rfc100.txt-
--
../data/rfc/rfc100.txt- NWG/RFC #s: 88, 90
../data/rfc/rfc100.txt-
../data/rfc/rfc100.txt- G.5 Illinois
../data/rfc/rfc100.txt- NWG/RFC #s: 76
../data/rfc/rfc100.txt-
../data/rfc/rfc100.txt: H. ACCOUNTING
../data/rfc/rfc100.txt-
../data/rfc/rfc100.txt- NWG/RFC #s: 77, 82
../data/rfc/rfc100.txt-
../data/rfc/rfc100.txt- I. OTHER
../data/rfc/rfc100.txt-
--
../data/rfc/rfc4201.txt- 3.6. Maximum Bandwidth ...................................... 8
../data/rfc/rfc4201.txt- 3.7. Maximum Reservable Bandwidth ........................... 8
../data/rfc/rfc4201.txt- 3.8. Unreserved Bandwidth ................................... 8
../data/rfc/rfc4201.txt- 3.9. Resource Classes (Administrative Groups) ............... 8
../data/rfc/rfc4201.txt- 3.10. Maximum LSP Bandwidth ................................. 8
../data/rfc/rfc4201.txt: 4. Bandwidth Accounting ......................................... 9
../data/rfc/rfc4201.txt- 5. Security Considerations ...................................... 9
../data/rfc/rfc4201.txt- 6. IANA Considerations .......................................... 9
../data/rfc/rfc4201.txt- 7. References ................................................... 10
../data/rfc/rfc4201.txt- 7.1. Normative References ................................... 10
../data/rfc/rfc4201.txt- 7.2. Informative References ................................. 11
--
../data/rfc/rfc4201.txt-
../data/rfc/rfc4201.txt- The details of how Maximum LSP Bandwidth is carried in IS-IS is given
../data/rfc/rfc4201.txt- in [GMPLS-ISIS]. The details of how Maximum LSP Bandwidth is carried
../data/rfc/rfc4201.txt- in OSPF is given in [GMPLS-OSPF].
../data/rfc/rfc4201.txt-
../data/rfc/rfc4201.txt:4. Bandwidth Accounting
../data/rfc/rfc4201.txt-
../data/rfc/rfc4201.txt- The RSVP (or CR-LDP) Traffic Control module, or its equivalent, on an
../data/rfc/rfc4201.txt- LSR with bundled links must apply admission control on a per-
../data/rfc/rfc4201.txt- component link basis. An LSP with a bandwidth requirement b and
../data/rfc/rfc4201.txt- setup priority p fits in a bundled link if at least one component
--
../data/rfc/rfc487.txt-privileges - for example, store commands can be implemented via an
../data/rfc/rfc487.txt-append mechanism. If I wanted a file sent to me I could create an empty
../data/rfc/rfc487.txt-file with unlimited append access. I would then inform the foreign user
../data/rfc/rfc487.txt-to store (append?) to that file.
../data/rfc/rfc487.txt-
../data/rfc/rfc487.txt: The problem of accounting is somewhat more complex. Clearly,
../data/rfc/rfc487.txt-storing a file in a user's directory can be charged to that user. When
../data/rfc/rfc487.txt-retrieving a file from a general system directory, there is no "user"
../data/rfc/rfc487.txt-specified, and overhead may have to be billed. The former case involved
../data/rfc/rfc487.txt-both CPU time for transfer and secondary storage charges for storing the
../data/rfc/rfc487.txt-new file. In the latter case, only CPU charges are involved, and these
--
../data/rfc/rfc6252.txt- The handover delay is attributed to several factors, such as
../data/rfc/rfc6252.txt- discovery, configuration, authentication, binding update, and media
../data/rfc/rfc6252.txt- delivery. Many of the security-related procedures, such as handover
../data/rfc/rfc6252.txt- keying and re-authentication procedures, deal with cases where there
../data/rfc/rfc6252.txt- is a single source of trust at the top, and the underlying
../data/rfc/rfc6252.txt: Authentication, Authorization, and Accounting (AAA) domain elements
../data/rfc/rfc6252.txt- trust the top source of trust and the keys it generates and
../data/rfc/rfc6252.txt- distributes. In this scenario, there is an appreciable delay in
../data/rfc/rfc6252.txt- re-establishing link-security-related parameters, such as
../data/rfc/rfc6252.txt- authentication, link key management, and access authorization during
../data/rfc/rfc6252.txt- inter-domain handover. The focus of this document is the design of a
--
../data/rfc/rfc6098.txt-3.2.2. Notification Message between a Foreign Agent and a Mobile Node
../data/rfc/rfc6098.txt-
../data/rfc/rfc6098.txt- There are two cases where an FA may send notification messages to an
../data/rfc/rfc6098.txt- MN -- one where it is relaying a message, the other where the
../data/rfc/rfc6098.txt- notification is triggered by a message from another network entity,
../data/rfc/rfc6098.txt: for example, an Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc6098.txt- node. (Notification messages between a AAA entity and the FA could
../data/rfc/rfc6098.txt- be based on RADIUS or Diameter, but this is out of scope for this
../data/rfc/rfc6098.txt- document.) If the notification is initiated by an FA, the FA may
../data/rfc/rfc6098.txt- also need to notify the HA about the event.
../data/rfc/rfc6098.txt-
--
../data/rfc/rfc8578.txt- Utilities often have very large private telecommunications networks
../data/rfc/rfc8578.txt- that can cover an entire territory/country. Until now, the main
../data/rfc/rfc8578.txt- purposes of these networks have been to (1) support transmission
../data/rfc/rfc8578.txt- network monitoring, control, and automation, (2) support remote
../data/rfc/rfc8578.txt- control of generation sites, and (3) provide FCAPS (Fault,
../data/rfc/rfc8578.txt: Configuration, Accounting, Performance, and Security) services from
../data/rfc/rfc8578.txt- centralized network operation centers.
../data/rfc/rfc8578.txt-
../data/rfc/rfc8578.txt- Going forward, one network will support the operation and maintenance
../data/rfc/rfc8578.txt- of electrical networks (generation, transmission, and distribution),
../data/rfc/rfc8578.txt- voice and data services for tens of thousands of employees and for
--
../data/rfc/rfc6728.txt-1. Introduction
../data/rfc/rfc6728.txt-
../data/rfc/rfc6728.txt- IPFIX- and PSAMP-compliant Monitoring Devices (routers, switches,
../data/rfc/rfc6728.txt- monitoring probes, Collectors, etc.) offer various configuration
../data/rfc/rfc6728.txt- possibilities that allow adapting network monitoring to the goals and
../data/rfc/rfc6728.txt: purposes of the application, such as accounting and charging, traffic
../data/rfc/rfc6728.txt- analysis, performance monitoring, and security monitoring. The use
../data/rfc/rfc6728.txt- of a common vendor-independent configuration data model for IPFIX-
../data/rfc/rfc6728.txt- and PSAMP-compliant Monitoring Devices facilitates network management
../data/rfc/rfc6728.txt- and configuration, especially if Monitoring Devices of different
../data/rfc/rfc6728.txt- implementers or manufacturers are deployed simultaneously. On the
--
../data/rfc/rfc6645.txt-Request for Comments: 6645 Cisco Systems, Inc.
../data/rfc/rfc6645.txt-Category: Informational July 2012
../data/rfc/rfc6645.txt-ISSN: 2070-1721
../data/rfc/rfc6645.txt-
../data/rfc/rfc6645.txt-
../data/rfc/rfc6645.txt: IP Flow Information Accounting and
../data/rfc/rfc6645.txt- Export Benchmarking Methodology
../data/rfc/rfc6645.txt-
../data/rfc/rfc6645.txt-Abstract
../data/rfc/rfc6645.txt-
../data/rfc/rfc6645.txt- This document provides a methodology and framework for quantifying
--
../data/rfc/rfc2801.txt-
../data/rfc/rfc2801.txt- o there are ways in which they can get their problems fixed through
../data/rfc/rfc2801.txt- the merchant (rather than the bank!)
../data/rfc/rfc2801.txt-
../data/rfc/rfc2801.txt- o there is a record of their transaction which can be used, for
../data/rfc/rfc2801.txt: example, to feed into accounting systems or, potentially, to
../data/rfc/rfc2801.txt- present to the tax authorities
../data/rfc/rfc2801.txt-
../data/rfc/rfc2801.txt-1.3 Baseline IOTP
../data/rfc/rfc2801.txt-
../data/rfc/rfc2801.txt- This specification is Baseline IOTP. It is a Baseline in that it
--
../data/rfc/rfc6934.txt- 4.2.2. All-ANCP ANX Control ...............................12
../data/rfc/rfc6934.txt- 5. Concept of Access Node Control Mechanism for PON-Based Access ..13
../data/rfc/rfc6934.txt- 6. Multicast ......................................................16
../data/rfc/rfc6934.txt- 6.1. Multicast Conditional Access ..............................16
../data/rfc/rfc6934.txt- 6.2. Multicast Admission Control ...............................18
../data/rfc/rfc6934.txt: 6.3. Multicast Accounting ......................................30
../data/rfc/rfc6934.txt- 7. Remote Connectivity Check ......................................31
../data/rfc/rfc6934.txt- 8. Access Topology Discovery ......................................32
../data/rfc/rfc6934.txt- 9. Access Loop Configuration ......................................34
../data/rfc/rfc6934.txt- 10. Security Considerations .......................................34
../data/rfc/rfc6934.txt- 11. Differences in ANCP Applicability between DSL and PON .........35
--
../data/rfc/rfc6934.txt- identifiers. In the case of N:1 representation, the single VLAN
../data/rfc/rfc6934.txt- inserted by ANX could correspond to the PON interface on the OLT.
../data/rfc/rfc6934.txt- The access loop is represented via Customer-Port-ID received in the
../data/rfc/rfc6934.txt- "Agent Circuit ID" sub-option in DHCP messages.
../data/rfc/rfc6934.txt-
../data/rfc/rfc6934.txt: The NAS can perform bandwidth accounting on received IGMP messages.
../data/rfc/rfc6934.txt- The video bandwidth is also consumed by any unicast video being
../data/rfc/rfc6934.txt: delivered to the CPE. NAS can perform video bandwidth accounting and
../data/rfc/rfc6934.txt- control on both IGMP messages and on requests for unicast video
../data/rfc/rfc6934.txt- streams when either all unicast admission control is done by the NAS
../data/rfc/rfc6934.txt- or an external policy server makes a request to the NAS for using
../data/rfc/rfc6934.txt- shared bandwidth with multicast as described later in the document.
../data/rfc/rfc6934.txt-
--
../data/rfc/rfc6934.txt- requesting a policy server for bandwidth-based admission control for
../data/rfc/rfc6934.txt- the VoD stream. After authorizing the request, the policy server can
../data/rfc/rfc6934.txt- send a request to the NAS for the required bandwidth if it needs to
../data/rfc/rfc6934.txt- use bandwidth that is shared with multicast. This request may be
../data/rfc/rfc6934.txt- based on a protocol outside of the scope of this document. The NAS
../data/rfc/rfc6934.txt: checks if the available video bandwidth (accounting for both
../data/rfc/rfc6934.txt- multicast and unicast) per subscriber and for the link to the OLT is
../data/rfc/rfc6934.txt- sufficient for the request. If it is, it temporarily reserves the
../data/rfc/rfc6934.txt- bandwidth and sends an ANCP admission request to the OLT for the
../data/rfc/rfc6934.txt- subscriber, indicating the desired VoD bandwidth. If the OLT has
../data/rfc/rfc6934.txt- sufficient bandwidth on the corresponding PON, it reserves that
--
../data/rfc/rfc6934.txt- NAS, the policy server may make the admission request to the NAS.
../data/rfc/rfc6934.txt- The NAS then sends an ANCP admission request to the OLT on behalf of
../data/rfc/rfc6934.txt- the policy server. The NAS returns an accept or reject to the policy
../data/rfc/rfc6934.txt- server if it gets a reject or accept, respectively, from the OLT.
../data/rfc/rfc6934.txt-
../data/rfc/rfc6934.txt:6.3. Multicast Accounting
../data/rfc/rfc6934.txt-
../data/rfc/rfc6934.txt- It may be desirable to perform accurate time- or volume-based
../data/rfc/rfc6934.txt: accounting per user or per access loop. If the ANX is performing the
../data/rfc/rfc6934.txt- traffic replication process, it knows when replication of a multicast
../data/rfc/rfc6934.txt- flow to a particular Access Port or user starts and stops. Multicast
../data/rfc/rfc6934.txt: accounting can be addressed in two ways:
../data/rfc/rfc6934.txt-
../data/rfc/rfc6934.txt-
../data/rfc/rfc6934.txt-
../data/rfc/rfc6934.txt-
../data/rfc/rfc6934.txt-
--
../data/rfc/rfc6934.txt-
../data/rfc/rfc6934.txt- - ANX keeps track of when replication starts or stops and reports
../data/rfc/rfc6934.txt- this information to the NAS for further processing. In this case,
../data/rfc/rfc6934.txt- ANCP can be used to send the information from the ANX to the NAS.
../data/rfc/rfc6934.txt- This can be done with the Information Report message. The NAS can
../data/rfc/rfc6934.txt: then generate the appropriate time and/or volume accounting
../data/rfc/rfc6934.txt- information per access loop and per multicast flow to be sent to
../data/rfc/rfc6934.txt: the accounting system. The ANCP requirements to support this
../data/rfc/rfc6934.txt- approach are specified in [RFC5851]. If the replication function
../data/rfc/rfc6934.txt- is distributed between the OLT and ONT/ONU, a query from the NAS
../data/rfc/rfc6934.txt- will result in OLT generating a query to the ONT/ONU.
../data/rfc/rfc6934.txt-
../data/rfc/rfc6934.txt- - ANX keeps track of when replication starts or stops and generates
../data/rfc/rfc6934.txt: the time- and/or volume-based accounting information per access
../data/rfc/rfc6934.txt- loop and per multicast flow, before sending it to a central
../data/rfc/rfc6934.txt: accounting system for logging. Since ANX communicates with this
../data/rfc/rfc6934.txt: accounting system directly, the approach does not require the use
../data/rfc/rfc6934.txt- of ANCP. It is therefore beyond the scope of this document. It
../data/rfc/rfc6934.txt- may also be desirable for the NAS to have the capability to
../data/rfc/rfc6934.txt- asynchronously query the ANX to obtain an instantaneous status
../data/rfc/rfc6934.txt- report related to multicast flows currently replicated by the ANX.
../data/rfc/rfc6934.txt- Such a reporting functionality could be useful for troubleshooting
--
../data/rfc/rfc6934.txt-Bitar, et al. Informational [Page 34]
../data/rfc/rfc6934.txt-
../data/rfc/rfc6934.txt-RFC 6934 ANCP in PON-Based Networks June 2013
../data/rfc/rfc6934.txt-
../data/rfc/rfc6934.txt-
../data/rfc/rfc6934.txt: User activity logging for accounting or tracking purposes could raise
../data/rfc/rfc6934.txt- privacy concerns if not appropriately protected. To protect such
../data/rfc/rfc6934.txt: information, logging/accounting information can be exchanged with the
../data/rfc/rfc6934.txt- corresponding server over a secure channel, and the information can
../data/rfc/rfc6934.txt- be stored securely with policy-driven controlled access.
../data/rfc/rfc6934.txt-
../data/rfc/rfc6934.txt-11. Differences in ANCP Applicability between DSL and PON
../data/rfc/rfc6934.txt-
--
../data/rfc/rfc3483.txt-Abstract
../data/rfc/rfc3483.txt-
../data/rfc/rfc3483.txt- Common Open Policy Services (COPS) Protocol (RFC 2748), defines the
../data/rfc/rfc3483.txt- capability of reporting information to the Policy Decision Point
../data/rfc/rfc3483.txt- (PDP). The types of report information are success, failure and
../data/rfc/rfc3483.txt: accounting of an installed state. This document focuses on the COPS
../data/rfc/rfc3483.txt: Report Type of Accounting and the necessary framework for the
../data/rfc/rfc3483.txt- monitoring and reporting of usage feedback for an installed state.
../data/rfc/rfc3483.txt-
../data/rfc/rfc3483.txt-Conventions used in this document
../data/rfc/rfc3483.txt-
../data/rfc/rfc3483.txt- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
--
../data/rfc/rfc3483.txt-RFC 3483 COPS Feedback Framework March 2003
../data/rfc/rfc3483.txt-
../data/rfc/rfc3483.txt-
../data/rfc/rfc3483.txt- The scope of this document is to describe the framework for policy
../data/rfc/rfc3483.txt- usage monitored and reported by the PEP and collected at the PDP.
../data/rfc/rfc3483.txt: The charging, rating and billing models, as well as other accounting
../data/rfc/rfc3483.txt- or statistics gathering events, detectable by the PDP are beyond the
../data/rfc/rfc3483.txt- scope of this framework.
../data/rfc/rfc3483.txt-
../data/rfc/rfc3483.txt-2 Overview
../data/rfc/rfc3483.txt-
--
../data/rfc/rfc3483.txt- like thresholds or a change in the data.
../data/rfc/rfc3483.txt-
../data/rfc/rfc3483.txt-3 Requirements for Normal Operations
../data/rfc/rfc3483.txt-
../data/rfc/rfc3483.txt- Per COPS [RFC2748], the PDP specifies the minimum feedback interval
../data/rfc/rfc3483.txt: in the Accounting Timer object that is included in the Client Accept
../data/rfc/rfc3483.txt- message during connection establishment. This specifies the maximum
../data/rfc/rfc3483.txt: frequency with which the PEP issues unsolicited accounting type
../data/rfc/rfc3483.txt- report messages. The purpose of this interval is to pace the number
../data/rfc/rfc3483.txt- of report messages sent to the PDP. It is not the goal of the
../data/rfc/rfc3483.txt- interval defined by the ACCT Timer value to provide precision
../data/rfc/rfc3483.txt- synchronization or timing.
../data/rfc/rfc3483.txt-
--
../data/rfc/rfc3483.txt- feedback reporting are defined by the PDP. Feedback policies, which
../data/rfc/rfc3483.txt- define the necessary selection and linkages to usage feedback
../data/rfc/rfc3483.txt- criteria, are included by the PDP in a Decision message to the PEP.
../data/rfc/rfc3483.txt- The usage feedback is then periodically reported by the PEP, at
../data/rfc/rfc3483.txt- intervals defined in the linkage policies at a rate no more
../data/rfc/rfc3483.txt: frequently than specified in the Accounting Timer object. Note that
../data/rfc/rfc3483.txt-
../data/rfc/rfc3483.txt-
../data/rfc/rfc3483.txt-
../data/rfc/rfc3483.txt-Rawlins, et al. Informational [Page 3]
../data/rfc/rfc3483.txt-
../data/rfc/rfc3483.txt-RFC 3483 COPS Feedback Framework March 2003
../data/rfc/rfc3483.txt-
../data/rfc/rfc3483.txt-
../data/rfc/rfc3483.txt- there are exceptions where reports containing feedback are provided
../data/rfc/rfc3483.txt: prior to the Accounting Timer interval (see section 6). The PDP may
../data/rfc/rfc3483.txt- also solicit usage feedback which is to be reported back immediately
../data/rfc/rfc3483.txt- by the PEP. Usage information may be cleared upon reporting. This
../data/rfc/rfc3483.txt- is specified in the usage policy criteria.
../data/rfc/rfc3483.txt-
../data/rfc/rfc3483.txt- The PEP monitors and tracks the usage feedback information. The PDP
../data/rfc/rfc3483.txt- is the collection point for the policy usage feedback information
../data/rfc/rfc3483.txt- reported by the PEP clients within the administrative domain. The
../data/rfc/rfc3483.txt: PDP may also collect other accounting event information that is
../data/rfc/rfc3483.txt- outside the scope of this document.
../data/rfc/rfc3483.txt-
../data/rfc/rfc3483.txt-4 Periodic Nature of Policy Usage Feedback
../data/rfc/rfc3483.txt-
../data/rfc/rfc3483.txt- Generally the policy usage feedback is periodic in nature and the
--
../data/rfc/rfc3483.txt- the interval defined by the PDP. The periodic unsolicited reports
../data/rfc/rfc3483.txt- are dictated by timer intervals and use a deterministic amount of
../data/rfc/rfc3483.txt- network resources.
../data/rfc/rfc3483.txt-
../data/rfc/rfc3483.txt- The PDP informs the PEP of the minimal feedback interval during
../data/rfc/rfc3483.txt: client connection establishment with the Accounting Timer object.
../data/rfc/rfc3483.txt- The PDP may specify feedback intervals in the specific usage feedback
../data/rfc/rfc3483.txt- policies as well. The unsolicited monitoring and reporting by the
../data/rfc/rfc3483.txt- PEP may be suspended and resumed at the direction of the PDP.
../data/rfc/rfc3483.txt-
../data/rfc/rfc3483.txt-4.1 Reporting Intervals
--
../data/rfc/rfc3483.txt-
../data/rfc/rfc3483.txt- The periodic feedback for a usage policy can be further defined in
../data/rfc/rfc3483.txt- terms of providing feedback if there is a change or providing
../data/rfc/rfc3483.txt- feedback periodically regardless of a change in value.
../data/rfc/rfc3483.txt-
../data/rfc/rfc3483.txt: The periodic interval is defined in terms of the Accounting Object,
../data/rfc/rfc3483.txt- ACCT Timer value. A single interval is equal to the number of
../data/rfc/rfc3483.txt- seconds specified by the ACCT Timer value. The PDP may define a
../data/rfc/rfc3483.txt- specific number of intervals, which are to pass before the PEP
../data/rfc/rfc3483.txt- provides the usage feedback for a specific policy in a report. When
../data/rfc/rfc3483.txt- the ACCT Timer value is equal to zero there is no unsolicited usage
--
../data/rfc/rfc3483.txt-
../data/rfc/rfc3483.txt- The PEP, upon receiving a solicit decision from the PDP, shall
../data/rfc/rfc3483.txt- provide the requested usage information and clear the usage
../data/rfc/rfc3483.txt- information if the usage policy requires that the attribute be
../data/rfc/rfc3483.txt- cleared after reporting. The PEP should continue to maintain the
../data/rfc/rfc3483.txt: same interval schedule as defined by the PDP in the Accounting Timer
../data/rfc/rfc3483.txt- object and established at client connection acceptance.
../data/rfc/rfc3483.txt-
../data/rfc/rfc3483.txt-5 Suspension, Resumption and Halting of Usage Monitoring and Reporting
../data/rfc/rfc3483.txt-
../data/rfc/rfc3483.txt- The PDP may direct the PEP to suspend usage feedback report messages
--
../data/rfc/rfc3483.txt-6 Solicited Feedback
../data/rfc/rfc3483.txt-
../data/rfc/rfc3483.txt- There may be instances when it is useful for the PDP to control the
../data/rfc/rfc3483.txt- feedback per an on-demand basis rather than a periodic basis. The
../data/rfc/rfc3483.txt- PDP may solicit the PEP for usage feedback with a Decision. The PDP
../data/rfc/rfc3483.txt: may solicit usage feedback at any time during the accounting interval
../data/rfc/rfc3483.txt- defined by the ACCT Timer. The PEP responds immediately and reports
../data/rfc/rfc3483.txt- the appropriate usage policies and should continue to follow the
../data/rfc/rfc3483.txt- usage feedback interval schedule established during connection
../data/rfc/rfc3483.txt- acceptance.
../data/rfc/rfc3483.txt-
--
../data/rfc/rfc524.txt-
../data/rfc/rfc524.txt- An Id is represented in the Protocol by the command:
../data/rfc/rfc524.txt-
../data/rfc/rfc524.txt- ID <id> <CA>
../data/rfc/rfc524.txt-
../data/rfc/rfc524.txt: Ids have nothing to do with accounting, and when required by a
../data/rfc/rfc524.txt- server, they're required only to protect that server from forgery
../data/rfc/rfc524.txt- or misrepresentation.
../data/rfc/rfc524.txt-
../data/rfc/rfc524.txt- INDIVIDUAL
../data/rfc/rfc524.txt-
--
../data/rfc/rfc524.txt- Agents (who implement the User Verification Function); and many hosts
../data/rfc/rfc524.txt- who implement the Delivery and Forwarding functions.
../data/rfc/rfc524.txt-
../data/rfc/rfc524.txt- In general, a host is free to implement any, all, or none of the
../data/rfc/rfc524.txt- functions defined by the Protocol; and a host is free to require a
../data/rfc/rfc524.txt: login (for purposes of accounting) before permitting a user process
../data/rfc/rfc524.txt- access to any of the function(s) it has implemented.
../data/rfc/rfc524.txt-
../data/rfc/rfc524.txt- An FTP server process who chooses to not implement MP or a particular
../data/rfc/rfc524.txt- MP function simply rejects the command that requests the
../data/rfc/rfc524.txt- unimplemented server with the reply:
--
../data/rfc/rfc524.txt- commands are:
../data/rfc/rfc524.txt-
../data/rfc/rfc524.txt- BYTE, SOCK, PASV, TYPE, STRU, MODE, REST, and SITE.
../data/rfc/rfc524.txt-
../data/rfc/rfc524.txt- The following commands borrowed from FTP are defined (also) as MP
../data/rfc/rfc524.txt: commands to permit changes of accounting parameters within the MP
../data/rfc/rfc524.txt: subsystem. The accounting parameters in force when the subsystem
../data/rfc/rfc524.txt- is entered apply (if necessary) within the subsystem until
../data/rfc/rfc524.txt- changed. Values to which the parameters may have been changed
../data/rfc/rfc524.txt- while in the subsystem continue in effect upon return to the FTP
../data/rfc/rfc524.txt- command space. The borrowed commands are:
../data/rfc/rfc524.txt-
--
../data/rfc/rfc2905.txt-
../data/rfc/rfc2905.txt- 5. Three types of AAA messages are required:
../data/rfc/rfc2905.txt-
../data/rfc/rfc2905.txt- - authorization requests and responses for obtaining
../data/rfc/rfc2905.txt- authorization,
../data/rfc/rfc2905.txt: - notification messages for accounting purposes, and
../data/rfc/rfc2905.txt- - information requests and responses for getting information
../data/rfc/rfc2905.txt- regarding the correct construction of requests and for querying
../data/rfc/rfc2905.txt- the database of notifications.
../data/rfc/rfc2905.txt-
../data/rfc/rfc2905.txt-8. Security Considerations
--
../data/rfc/rfc2905.txt- Requirements", Work in Progress.
../data/rfc/rfc2905.txt-
../data/rfc/rfc2905.txt- [10] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
../data/rfc/rfc2905.txt-
../data/rfc/rfc2905.txt- [11] Glass, Steven, et al, "Mobile IP Authentication, Authorization,
../data/rfc/rfc2905.txt: and Accounting Requirements", Work in Progress.
../data/rfc/rfc2905.txt-
../data/rfc/rfc2905.txt- [12] Hiller, Tom, et al., "cdma2000 Wireless Data Requirements for
../data/rfc/rfc2905.txt- AAA", Work in Progress.
../data/rfc/rfc2905.txt-
../data/rfc/rfc2905.txt- [13] Neilson, Rob, Jeff Wheeler, Francis Reichmeyer, and Susan Hares,
--
../data/rfc/rfc1114.txt- which is "transparent" so that the organizations appear to be the
../data/rfc/rfc1114.txt- issuers with regard to certificate formats and validation procedures.
../data/rfc/rfc1114.txt- This is effected by having RSADSI generate and hold the secret
../data/rfc/rfc1114.txt- components used to sign certificates on behalf of organizations. The
../data/rfc/rfc1114.txt- motivation for RSADSI's role in certificate signing is twofold.
../data/rfc/rfc1114.txt: First, it simplifies accounting controls in support of licensing,
../data/rfc/rfc1114.txt- ensuring that RSADSI is paid for each certificate. Second, it
../data/rfc/rfc1114.txt- contributes to the overall integrity of the system by establishing a
../data/rfc/rfc1114.txt- uniform, high level of protection for the private-components used to
../data/rfc/rfc1114.txt- sign certificates. If an organization were to sign certificates
../data/rfc/rfc1114.txt- directly on behalf of its affiliated users, the organization would
../data/rfc/rfc1114.txt: have to establish very stringent security and accounting mechanisms
../data/rfc/rfc1114.txt- and enter into (elaborate) legal agreements with RSADSI in order to
../data/rfc/rfc1114.txt- provide a comparable level of assurance. Requests by organizations
../data/rfc/rfc1114.txt- to perform direct certificate signing will be considered on a case-
../data/rfc/rfc1114.txt- by-case basis, but organizations are strongly urged to make use of
../data/rfc/rfc1114.txt- the facilities proposed by this RFC.
--
../data/rfc/rfc1114.txt- organization certificate, it would need to contact RSADSI to discuss
../data/rfc/rfc1114.txt- security safeguards, special legal agreements, etc. A number of
../data/rfc/rfc1114.txt- requirements would be imposed on an organization if such an approach
../data/rfc/rfc1114.txt- were persued. The organization would be required to execute
../data/rfc/rfc1114.txt- additional legal instruments with RSADSI, e.g., to ensure proper
../data/rfc/rfc1114.txt: accounting for certificates generated by the organization. Special
../data/rfc/rfc1114.txt- software will be required to support the certificate signing process,
../data/rfc/rfc1114.txt- distinct from the software required for an ON. Stringent procedural,
../data/rfc/rfc1114.txt- physical, personnel and computer security safeguards would be
../data/rfc/rfc1114.txt- required to support this process, to maintain a relatively high level
../data/rfc/rfc1114.txt- of security for the system as a whole. Thus, at this time, it is not
--
../data/rfc/rfc1688.txt- future services.
../data/rfc/rfc1688.txt-
../data/rfc/rfc1688.txt- Ownership information could be used by other nodes to ascertain the
../data/rfc/rfc1688.txt- current topological location of the Mobile Node.
../data/rfc/rfc1688.txt-
../data/rfc/rfc1688.txt: Ownership information could also be used for generation of accounting
../data/rfc/rfc1688.txt- records.
../data/rfc/rfc1688.txt-
../data/rfc/rfc1688.txt-
../data/rfc/rfc1688.txt-
../data/rfc/rfc1688.txt-
--
../data/rfc/rfc7862.txt-
../data/rfc/rfc7862.txt- size The logical file size of the file.
../data/rfc/rfc7862.txt-
../data/rfc/rfc7862.txt- space_used The size in bytes that the file occupies on disk.
../data/rfc/rfc7862.txt-
../data/rfc/rfc7862.txt: While these attributes are sufficient for space accounting in
../data/rfc/rfc7862.txt- traditional file systems, they prove to be inadequate in modern file
../data/rfc/rfc7862.txt- systems that support block-sharing. In such file systems, multiple
../data/rfc/rfc7862.txt- inodes (the metadata portion of the file system object) can point to
../data/rfc/rfc7862.txt- a single block with a block reference count to guard against
../data/rfc/rfc7862.txt- premature freeing. Having a way to tell the number of blocks that
--
../data/rfc/rfc2702.txt- 3.2 The Fundamental Problem of Traffic Engineering Over MPLS . 9
../data/rfc/rfc2702.txt- 4.0 Augmented Capabilities for Traffic Engineering Over MPLS . 10
../data/rfc/rfc2702.txt- 5.0 Traffic Trunk Attributes and Characteristics ........... 10
../data/rfc/rfc2702.txt- 5.1 Bidirectional Traffic Trunks ............................. 11
../data/rfc/rfc2702.txt- 5.2 Basic Operations on Traffic Trunks ....................... 12
../data/rfc/rfc2702.txt: 5.3 Accounting and Performance Monitoring .................... 12
../data/rfc/rfc2702.txt-
../data/rfc/rfc2702.txt-
../data/rfc/rfc2702.txt-
../data/rfc/rfc2702.txt-Awduche, et al. Informational [Page 1]
../data/rfc/rfc2702.txt-
--
../data/rfc/rfc2702.txt-
../data/rfc/rfc2702.txt- The above are considered the basic operations on traffic trunks.
../data/rfc/rfc2702.txt- Additional operations are also possible such as policing and traffic
../data/rfc/rfc2702.txt- shaping.
../data/rfc/rfc2702.txt-
../data/rfc/rfc2702.txt:5.3 Accounting and Performance Monitoring
../data/rfc/rfc2702.txt-
../data/rfc/rfc2702.txt: Accounting and performance monitoring capabilities are very important
../data/rfc/rfc2702.txt- to the billing and traffic characterization functions. Performance
../data/rfc/rfc2702.txt: statistics obtained from accounting and performance monitoring
../data/rfc/rfc2702.txt-
../data/rfc/rfc2702.txt-
../data/rfc/rfc2702.txt-
../data/rfc/rfc2702.txt-
../data/rfc/rfc2702.txt-Awduche, et al. Informational [Page 12]
--
../data/rfc/rfc1272.txt- G. Ruth
../data/rfc/rfc1272.txt- BBN
../data/rfc/rfc1272.txt- November 1991
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt: INTERNET ACCOUNTING: BACKGROUND
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-Status of this Memo
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- This memo provides information for the Internet community. It does
../data/rfc/rfc1272.txt- not specify an Internet standard. Distribution of this memo is
../data/rfc/rfc1272.txt- unlimited.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-1. Statement of Purpose
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- This document provides background information for the "Internet
../data/rfc/rfc1272.txt: Accounting Architecture" and is the first of a three document set:
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt: Internet Accounting Background & Status (this document)
../data/rfc/rfc1272.txt: Internet Accounting Architecture (under construction)
../data/rfc/rfc1272.txt: Internet Accounting Meter Service (under construction)
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- The focus at this time is on defining METER SERVICES and USAGE
../data/rfc/rfc1272.txt- REPORTING which provide basic semantics for measuring network
../data/rfc/rfc1272.txt- utilization, a syntax, and a data reporting protocol. The intent is
../data/rfc/rfc1272.txt- to produce a set of standards that is of practical use for early
../data/rfc/rfc1272.txt: experimentation with usage reporting as an internet accounting
../data/rfc/rfc1272.txt- mechanism.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- The architecture should be expandable as additional experience is
../data/rfc/rfc1272.txt: gained. The short-term Internet Accounting solution is intended to
../data/rfc/rfc1272.txt- merge with OSI and Autonomous Network Research Group (ANRG) efforts
../data/rfc/rfc1272.txt- and be superseded by those efforts in the long term. The OSI
../data/rfc/rfc1272.txt: accounting working groups are currently defining meter syntax and
../data/rfc/rfc1272.txt- reporting protocols. The ANRG research group is currently
../data/rfc/rfc1272.txt: researching economic models and accounting tools for the Internet
../data/rfc/rfc1272.txt- environment.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt: Internet Accounting as described here does not wrestle with the
../data/rfc/rfc1272.txt- applications of usage reporting, such as monitoring and enforcing
../data/rfc/rfc1272.txt- network policy; nor does it recommend approaches to billing or tackle
../data/rfc/rfc1272.txt- such thorny issues as who pays for packet retransmission.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- This document provides background and tutorial information on issues
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-Mills, Hirsh, & Ruth [Page 1]
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt:RFC 1272 Internet Accounting: Background November 1991
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- surrounding the architecture, or in a sense, an explanation of
../data/rfc/rfc1272.txt: choices made in the Internet Accounting Architecture.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-2. Goals for a Usage Reporting Architecture
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt: We have adopted the accounting framework and terminology used by OSI
../data/rfc/rfc1272.txt- (ISO 7498-4 OSI Reference Model Part 4: Management Framework). This
../data/rfc/rfc1272.txt: framework defines a generalized accounting management activity which
../data/rfc/rfc1272.txt- includes calculations, usage reporting to users and providers and
../data/rfc/rfc1272.txt- enforcing various limits on the use of resources. Our own ambitions
../data/rfc/rfc1272.txt- are considerably more modest in that we are defining an architecture
../data/rfc/rfc1272.txt- to be used over the short- term (until ISO and ANRG have final
../data/rfc/rfc1272.txt- pronouncement and standards) that is limited to network USAGE
../data/rfc/rfc1272.txt- REPORTING.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt: The OSI accounting model defines three basic entities:
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- 1) the METER, which performs measurements and aggregates the
../data/rfc/rfc1272.txt- results of those measurements;
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- 2) the COLLECTOR, which is responsible for the integrity and
--
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-Mills, Hirsh, & Ruth [Page 2]
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt:RFC 1272 Internet Accounting: Background November 1991
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- network usage. Reporting alone is not sufficient to
../data/rfc/rfc1272.txt- enforce compliance with policies, but reports can
../data/rfc/rfc1272.txt- indicate whether it is necessary to develop additional
--
../data/rfc/rfc1272.txt- This offers an additional source of computational load
../data/rfc/rfc1272.txt- and network traffic due to the counting operations,
../data/rfc/rfc1272.txt- managing the reporting system, collecting the reported
../data/rfc/rfc1272.txt- data, and storing the resulting counts. Overhead
../data/rfc/rfc1272.txt- increases with the accuracy and reliability of the
../data/rfc/rfc1272.txt: accounting data.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- o Post-processing overhead.
../data/rfc/rfc1272.txt- Resources are required to maintain the post-processing
../data/rfc/rfc1272.txt: tasks of maintaining the accounting database, generating
../data/rfc/rfc1272.txt- reports, and, if appropriate, distributing bills,
../data/rfc/rfc1272.txt- collecting revenue, servicing subscribers.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- o Security overhead.
../data/rfc/rfc1272.txt- The use of security mechanisms will increase the overall
../data/rfc/rfc1272.txt: cost of accounting. Since accounting collects detailed
../data/rfc/rfc1272.txt- information about subscriber behavior on the network and
../data/rfc/rfc1272.txt- since these counts may also represent a flow of money, it
../data/rfc/rfc1272.txt: is necessary to have mechanisms to protect accounting
../data/rfc/rfc1272.txt- information from unauthorized disclosure or manipulation.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- The balance between cost and benefit is regulated by the GRANULARITY
../data/rfc/rfc1272.txt: of accounting information collected. This balance is policy-
../data/rfc/rfc1272.txt: dependent. To minimize costs and maximize benefit, accounting detail
../data/rfc/rfc1272.txt- is limited to the minimum amount to provide the necessary information
../data/rfc/rfc1272.txt- for the research and implementation of a particular policy.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
--
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-Mills, Hirsh, & Ruth [Page 3]
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt:RFC 1272 Internet Accounting: Background November 1991
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-3.2. Network Policy and Usage Reporting
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt: Accounting requirements are driven by policy. Conversely, policy is
../data/rfc/rfc1272.txt- typically influenced by the available management/reporting tools and
../data/rfc/rfc1272.txt- their cost. This section is NOT a recommendation for billing
../data/rfc/rfc1272.txt- practices, but intended to provide additional background for
../data/rfc/rfc1272.txt- understanding the problems involved in implementing a simple,
../data/rfc/rfc1272.txt- adequate usage reporting system.
--
../data/rfc/rfc1272.txt- increasingly enmeshed (more cross-connections) and more diversified
../data/rfc/rfc1272.txt- (different charters and usage patterns). Each of these
../data/rfc/rfc1272.txt- administrations has different policies and by-laws about who may use
../data/rfc/rfc1272.txt- an individual network, who pays for it, and how the payment is
../data/rfc/rfc1272.txt- determined. Also, each administration balances the OVERHEAD costs of
../data/rfc/rfc1272.txt: accounting (metering, reporting, billing, collecting) against the
../data/rfc/rfc1272.txt- benefits of identifying usage and allocating costs.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- Some members of the Internet community are concerned that the
../data/rfc/rfc1272.txt- introduction of usage reporting will encourage new billing policies
../data/rfc/rfc1272.txt- which are detrimental to the current Internet infrastructure (though
--
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-Mills, Hirsh, & Ruth [Page 4]
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt:RFC 1272 Internet Accounting: Background November 1991
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- o QUANTIFY NETWORK IMPROVEMENTS,
../data/rfc/rfc1272.txt- (measure user and vendor efficiency in how network
../data/rfc/rfc1272.txt- resources are consumed to provide end-user data transport
../data/rfc/rfc1272.txt- service) and
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- o MEASURE COMPLIANCE WITH POLICY.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt: Accounting policies for network traffic already exist. But they are
../data/rfc/rfc1272.txt- usually based on network parameters which change seldom, if at all.
../data/rfc/rfc1272.txt- Such parameters require little monitoring (the line speed of a
../data/rfc/rfc1272.txt- physical connection, e.g.,Ethernet, 9600 baud, FDDI). The connection
../data/rfc/rfc1272.txt- to the network is then charged to the subscriber as a FLAT-FEE
../data/rfc/rfc1272.txt- regardless of the amount of traffic passed across the connection and
--
../data/rfc/rfc1272.txt- Predictable monthly charges. No overhead costs for
../data/rfc/rfc1272.txt- counting packets and preparing usage-based reports.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- o TECHNICAL:
../data/rfc/rfc1272.txt- Easing the sharing of resources. Eliminating the
../data/rfc/rfc1272.txt: headaches of needing another layer of accounting in proxy
../data/rfc/rfc1272.txt- servers which associate their usage with their clients'.
../data/rfc/rfc1272.txt- Examples of proxy servers which generate network traffic
../data/rfc/rfc1272.txt- on behalf of the actual user or subscriber are mail
../data/rfc/rfc1272.txt- daemons, network file servers, and print spoolers.
../data/rfc/rfc1272.txt-
--
../data/rfc/rfc1272.txt- In other cases USAGE-SENSITIVE charges may be preferred or required
../data/rfc/rfc1272.txt- by a local administration's policy. Government regulations or the
../data/rfc/rfc1272.txt- wishes of subscribers with low or intermittent traffic patterns may
../data/rfc/rfc1272.txt- force the issue (note: FLAT FEES are beneficial for heavy network
../data/rfc/rfc1272.txt- users. USAGE SENSITVE charges generally benefit the low-volume
../data/rfc/rfc1272.txt: user). Where usage-sensitive accounting is used, cost ceilings and
../data/rfc/rfc1272.txt- floors may still be established by static parameters, such as "pipe
../data/rfc/rfc1272.txt- size" for fixed connections or "connection time" for dial-up
../data/rfc/rfc1272.txt- connection, to satisfy the need for some predictability.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-Mills, Hirsh, & Ruth [Page 5]
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt:RFC 1272 Internet Accounting: Background November 1991
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- Different billing schemes may be employed depending on network
../data/rfc/rfc1272.txt- measures of distance. For example, local network traffic may be
../data/rfc/rfc1272.txt- flat-rate and remote internet traffic may be usage-based, analogous
--
../data/rfc/rfc1272.txt- telephone companies.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- The ANRG is independently investigating policy models and
../data/rfc/rfc1272.txt- infrastructure economics for billing and cost recovery.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt:3.3. The Nature of Usage Accounting
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt: Although the exact requirements for internet usage accounting will
../data/rfc/rfc1272.txt- vary from one network administration to the next and will depend on
../data/rfc/rfc1272.txt- policies and cost trade-offs, it is possible to characterize the
../data/rfc/rfc1272.txt- problem in some broad terms and thereby bound it. Rather than try to
../data/rfc/rfc1272.txt- solve the problem in exhaustive generality (providing for every
../data/rfc/rfc1272.txt: imaginable set of accounting requirements), some assumptions about
../data/rfc/rfc1272.txt: usage accounting are posited in order to make the problem tractable
../data/rfc/rfc1272.txt- and to render implementations feasible. Since these assumptions form
../data/rfc/rfc1272.txt- the basis for our architectural and design work, it is important to
../data/rfc/rfc1272.txt- make them explicit from the outset and hold them up to the scrutiny
../data/rfc/rfc1272.txt- of the Internet community.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt:3.3.1. A Model for Internet Accounting
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- We begin with the assumption that there is a "network administrator"
../data/rfc/rfc1272.txt: or "network administration" to whom internet accounting is of
../data/rfc/rfc1272.txt- interest. He "owns" and operates some subset of the internet (one or
../data/rfc/rfc1272.txt- more connected networks)that may be called his "administrative
../data/rfc/rfc1272.txt- domain". This administrative domain has well defined boundaries.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
--
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- The network administrator is interested in 1) traffic within his
../data/rfc/rfc1272.txt- boundaries and 2) traffic crossing his boundaries. Within his
../data/rfc/rfc1272.txt- boundaries he may be interested in end-system to end-system
../data/rfc/rfc1272.txt: accounting or accounting at coarser granularities (e.g., department
../data/rfc/rfc1272.txt- to department).
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-Mills, Hirsh, & Ruth [Page 6]
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt:RFC 1272 Internet Accounting: Background November 1991
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt: The network administrator is usually not interested in accounting for
../data/rfc/rfc1272.txt- end-systems outside his administrative domain; his primary concern is
../data/rfc/rfc1272.txt: accounting to the level of other ADJACENT (directly connected)
../data/rfc/rfc1272.txt- administrative domains. Consider the viewpoint of the administrator
../data/rfc/rfc1272.txt- for domain X of the internet. The idea is that he will send each
../data/rfc/rfc1272.txt- adjacent administrative domain a bill (or other statement of
../data/rfc/rfc1272.txt: accounting) for its use of his resources and it will send him a bill
../data/rfc/rfc1272.txt- for his use of its resources. When he receives an aggregate bill
../data/rfc/rfc1272.txt- from Network A, if he wishes to allocate the charges to end users or
../data/rfc/rfc1272.txt- subsystems within his domain, it is HIS responsibility to collect
../data/rfc/rfc1272.txt: accounting data about how they used the resources of Network A. If
../data/rfc/rfc1272.txt- the "user" is in fact another administrative domain, B, (on whose
../data/rfc/rfc1272.txt- behalf X was using A's resources) the administrator for X just sends
../data/rfc/rfc1272.txt- his counterpart in B a bill for the part of X's bill attributable to
../data/rfc/rfc1272.txt- B's usage. If B was passing traffic for C, them B bills C for the
../data/rfc/rfc1272.txt- appropriate portion X's charges, and so on, until the charges
../data/rfc/rfc1272.txt- percolate back to the original end user, say G. Thus, the
../data/rfc/rfc1272.txt- administrator for X does not have to account for G's usage; he only
../data/rfc/rfc1272.txt- has to account for the usage of the administrative domains directly
../data/rfc/rfc1272.txt- adjacent to himself.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt: This paradigm of recursive accounting may, of course, be used WITHIN
../data/rfc/rfc1272.txt- an administrative domain that is (logically) comprised of sub-
../data/rfc/rfc1272.txt- administrative domains.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- The discussion of the preceding paragraphs applies to a general mesh
../data/rfc/rfc1272.txt- topology, in which any Internet constituent domain may act as a
../data/rfc/rfc1272.txt- service provider for any connected domain. Although the Internet
../data/rfc/rfc1272.txt- topology is in fact such a mesh, there is a general hierarchy to its
../data/rfc/rfc1272.txt- structure and hierarchical routing (when implemented) will make it
../data/rfc/rfc1272.txt- logically hierarchical as far as traffic flow is concerned. This
../data/rfc/rfc1272.txt: logical hierarchy permits a simplification of the usage accounting
../data/rfc/rfc1272.txt- perspective.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- At the bottom of the service hierarchy a service-consuming host sits
../data/rfc/rfc1272.txt- on one of many "stub" networks. These are interconnected into an
../data/rfc/rfc1272.txt- enterprise-wide extended LAN, which in turn receives Internet
--
../data/rfc/rfc1272.txt- Regional backbones receive national transport services from national
../data/rfc/rfc1272.txt- backbones such as NSFnet, Alternet, PSInet, CERFnet, NSInet, or
../data/rfc/rfc1272.txt- Nordunet. In this scheme each level in the hierarchy has a
../data/rfc/rfc1272.txt- constituency, a group for which usage reporting is germane, in the
../data/rfc/rfc1272.txt- level underneath it. In the case of the NSFnet the natural
../data/rfc/rfc1272.txt: constituency, for accounting purposes at least, is the regional nets
../data/rfc/rfc1272.txt- (MIDnet, SURAnet,...). For the regionals it will be their member
../data/rfc/rfc1272.txt- institutions; for the institutions, their stub networks; and for the
../data/rfc/rfc1272.txt- stubs, their individual hosts.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-Mills, Hirsh, & Ruth [Page 7]
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt:RFC 1272 Internet Accounting: Background November 1991
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-3.3.2. Implications of the Model
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- The significance of the model sketched above is that Internet
../data/rfc/rfc1272.txt: accounting must be able to support accounting for adjacent
../data/rfc/rfc1272.txt: (intermediate) systems, as well as end-system accounting. Adjacent
../data/rfc/rfc1272.txt: system accounting information cannot be derived from end-system
../data/rfc/rfc1272.txt: accounting (even if complete end-system accounting were feasible)
../data/rfc/rfc1272.txt- because traffic from an end-system may reach the administrative
../data/rfc/rfc1272.txt- domain of interest through different adjacent domains, and it is the
../data/rfc/rfc1272.txt- adjacent domain through which it passes that is of interest.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt: The need to support accounting for adjacent intermediate systems
../data/rfc/rfc1272.txt: means that internet accounting will require information not present
../data/rfc/rfc1272.txt- in internet protocol headers (these headers contain source and
../data/rfc/rfc1272.txt- destination addresses of end-systems only). This information may
../data/rfc/rfc1272.txt- come from lower layer protocols (network or link layer) or from
../data/rfc/rfc1272.txt- configuration information for boundary components (e.g., "what system
../data/rfc/rfc1272.txt- is connected to port 5 of this IP router").
--
../data/rfc/rfc1272.txt- (domains)). The assignment of packets to flows may be done by
../data/rfc/rfc1272.txt- executing a series of rules. Meters can reasonably be implemented in
../data/rfc/rfc1272.txt- any of three environments -- dedicated monitors, in routers or in
../data/rfc/rfc1272.txt- general-purpose systems.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt: Meter location is a critical decision in internet accounting. An
../data/rfc/rfc1272.txt- important criterion for selecting meter location is cost, i.e.,
../data/rfc/rfc1272.txt: REDUCING ACCOUNTING OVERHEAD and MINIMIZING THE COST OF
../data/rfc/rfc1272.txt- IMPLEMENTATION.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt: In the trade-off between overhead (cost of accounting) and detail,
../data/rfc/rfc1272.txt- ACCURACY and RELIABILITY play a decisive role. Full accuracy and
../data/rfc/rfc1272.txt: reliability for accounting purposes require that EVERY packet must be
../data/rfc/rfc1272.txt- examined. However, if the requirement for accuracy and reliability
../data/rfc/rfc1272.txt- is relaxed, statistical sampling may be more practical and
../data/rfc/rfc1272.txt: sufficiently accurate, and DETAILED ACCOUNTING is not required at
../data/rfc/rfc1272.txt- all. Accuracy and reliability requirements may be less stringent
../data/rfc/rfc1272.txt- when the purpose of usage-reporting is solely to understand network
../data/rfc/rfc1272.txt- behavior, for network design and performance tuning, or when usage
../data/rfc/rfc1272.txt- reporting is used to approximate cost allocations to users as a
../data/rfc/rfc1272.txt- percentage of total fees.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt: Overhead costs are minimized by accounting at the coarsest acceptable
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-Mills, Hirsh, & Ruth [Page 8]
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt:RFC 1272 Internet Accounting: Background November 1991
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- GRANULARITY, i.e., using the greatest amount of AGGREGATION possible
../data/rfc/rfc1272.txt: to limit the number of accounting records generated, their size, and
../data/rfc/rfc1272.txt- the frequency with which they are transmitted across the network or
../data/rfc/rfc1272.txt- otherwise stored.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- The other cost factor lies in implementation. Implementation will
../data/rfc/rfc1272.txt- necessitate the development and introduction of hardware and software
--
../data/rfc/rfc1272.txt- administrative boundaries and data collected such that service
../data/rfc/rfc1272.txt- provider and consumer are able to reconcile their activities.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- Routers (and/or bridges) are by definition and design placed
../data/rfc/rfc1272.txt- (topologically) at these boundaries and so it follows that the most
../data/rfc/rfc1272.txt: generally convenient place to position accounting meters is in or
../data/rfc/rfc1272.txt- near the router. But again this depends on the underlying transport.
../data/rfc/rfc1272.txt- Whenever the service-providing network is broadcast (e.g., bus-
../data/rfc/rfc1272.txt- based), not extended (i.e., without bridging or routing), then meter
../data/rfc/rfc1272.txt- placement is of no particular consequence. If one were generating
../data/rfc/rfc1272.txt- usage reports for a stub LAN, meters could reasonably be placed in a
--
../data/rfc/rfc1272.txt- are the ultimate source and sink of all traffic. Routers monitor all
../data/rfc/rfc1272.txt- traffic which passes IN or OUT of each network. Motivations for
../data/rfc/rfc1272.txt- selecting the routers as the metering points are:
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- o Minimization of cost and overhead.
../data/rfc/rfc1272.txt: (by concentrating the accounting function). Centralize
../data/rfc/rfc1272.txt- and minimize in terms of number of geographical or
../data/rfc/rfc1272.txt- administrative regions, number of protocols monitored,
../data/rfc/rfc1272.txt- and number of separate implementations modified. (Hosts
../data/rfc/rfc1272.txt- are too diverse and numerous for easy standardization.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-Mills, Hirsh, & Ruth [Page 9]
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt:RFC 1272 Internet Accounting: Background November 1991
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- Routers concentrate traffic and are more homogeneous.)
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- o Traffic control.
--
../data/rfc/rfc1272.txt- in meter status (e.g., exceeding a quota) would result in
../data/rfc/rfc1272.txt- an active influence on network traffic (the router starts
../data/rfc/rfc1272.txt- denying access). A passive measuring device cannot
../data/rfc/rfc1272.txt- control network access in response to detecting state.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt: o Intermediate system accounting.
../data/rfc/rfc1272.txt: As discussed above, internet accounting includes both
../data/rfc/rfc1272.txt: end-system and intermediate system accounting. Hosts see
../data/rfc/rfc1272.txt- only end-system traffic; routers see both the end-systems
../data/rfc/rfc1272.txt- (internet source and destination) and the adjacent
../data/rfc/rfc1272.txt- intermediate systems.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- Therefore, meters should be placed at:
--
../data/rfc/rfc1272.txt- o administrative boundaries
../data/rfc/rfc1272.txt- only for measuring inter-domain traffic;
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- o stub networks
../data/rfc/rfc1272.txt- for measuring intra-domain traffic. For intra-domain
../data/rfc/rfc1272.txt: traffic, the requirement for performing accounting at
../data/rfc/rfc1272.txt- almost every router is a disincentive for implementing a
../data/rfc/rfc1272.txt- usage-based charging policy.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-4.2. Meter Types
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- Four possible types of metering technology are:
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- o Network monitors:
../data/rfc/rfc1272.txt- These measure only traffic WITHIN a single network. They
../data/rfc/rfc1272.txt: include LAN monitors, X.25 call accounting systems and
../data/rfc/rfc1272.txt- traffic monitors in bridges.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- o Line monitors:
../data/rfc/rfc1272.txt- These count packets flowing across a circuit. They would
../data/rfc/rfc1272.txt- be placed on inter-router trunks and on router ports.
--
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-Mills, Hirsh, & Ruth [Page 10]
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt:RFC 1272 Internet Accounting: Background November 1991
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-4.3. Meter Structure
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- While topology argues in favor of meters in routers, granularity and
../data/rfc/rfc1272.txt- security favor dedicated monitors. The GRANULARITY of the
../data/rfc/rfc1272.txt- accountable entity (and its attributes) affects the amount of
../data/rfc/rfc1272.txt: overhead incurred for accounting. Each entity/attribute/reporting
../data/rfc/rfc1272.txt- interval combination is a separate meter. Each individual meter
../data/rfc/rfc1272.txt- takes up local memory and requires additional memory or network
../data/rfc/rfc1272.txt- resources when the meter reports to the application. Memory is a
../data/rfc/rfc1272.txt- limited resource, and there are cost implications to expanding memory
../data/rfc/rfc1272.txt- significantly or increasing the frequency of reporting. The number
--
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- ENTITY: Entities range across the spectrum from the coarsest
../data/rfc/rfc1272.txt- granularity, PORT (a local view with a unique designation for the
../data/rfc/rfc1272.txt- subscriber port through which packets enter and exit "my"
../data/rfc/rfc1272.txt- network) through NETWORK and HOST to USER (not defined here).
../data/rfc/rfc1272.txt: The port is the minimum granularity of accounting. HOST is the
../data/rfc/rfc1272.txt- finest granularity defined here. Where verification is required,
../data/rfc/rfc1272.txt: a network should be able to perform accounting at the granularity
../data/rfc/rfc1272.txt- its subscribers use. Hosts are ultimately responsible for
../data/rfc/rfc1272.txt- identifying the end user, since only the hosts have unambiguous
../data/rfc/rfc1272.txt- access to user identification. This information could be shared
../data/rfc/rfc1272.txt- with the network, but it is the host's responsibility to do so,
../data/rfc/rfc1272.txt- and there is no mechanism in place at this time (e.g., an IP
--
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-Mills, Hirsh, & Ruth [Page 11]
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt:RFC 1272 Internet Accounting: Background November 1991
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- categorization of packets. The finest granularity would be to
../data/rfc/rfc1272.txt- maintain state information about the higher-levels protocols or
../data/rfc/rfc1272.txt- type of service being used by communicating processes across the
--
../data/rfc/rfc1272.txt- packet counts and byte counts. They may also be time stamps -
../data/rfc/rfc1272.txt- start time and stop time, or reasons for starting or stopping
../data/rfc/rfc1272.txt- reporting.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- REPORTING INTERVAL: At the very finest level of granularity,
../data/rfc/rfc1272.txt: each data packet might generate a separate accounting record. To
../data/rfc/rfc1272.txt- report traffic at this level of detail would require
../data/rfc/rfc1272.txt: approximately one packet of accounting information for every data
../data/rfc/rfc1272.txt- packet sent. The reporting interval is then zero and no memory
../data/rfc/rfc1272.txt- will be needed for flow record storage. For a non-zero reporting
../data/rfc/rfc1272.txt- interval flow records must be maintained in memory. Storage for
../data/rfc/rfc1272.txt- stale (old, infrequent) flows may be recycled when their data has
../data/rfc/rfc1272.txt- been reported. As the reporting interval increases, more and
../data/rfc/rfc1272.txt- more stale records accumulate.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- The feasibility of a particular group of granularities varies
../data/rfc/rfc1272.txt- with the PERFORMANCE characteristics of the network (link speed,
../data/rfc/rfc1272.txt- link bandwidth, router processing speed, router memory), as well
../data/rfc/rfc1272.txt: as the COST of accounting balanced against the requirement for
../data/rfc/rfc1272.txt- DETAIL. Since technological advances can quickly obsolete
../data/rfc/rfc1272.txt- current technical limitations, and since the policy structure and
../data/rfc/rfc1272.txt- economics of the Internet are in flux, meters will be defined
../data/rfc/rfc1272.txt- with VARYING GRANULARITY which is regulated according to the
../data/rfc/rfc1272.txt- traffic requirements of the individual network or administration
--
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-Mills, Hirsh, & Ruth [Page 12]
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt:RFC 1272 Internet Accounting: Background November 1991
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- Meters can generate large, unstructured amounts of information
../data/rfc/rfc1272.txt- and the essential collection issue revolves around mapping
../data/rfc/rfc1272.txt- collection activities into an SNMP framework (or, to the extent
--
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- o local and remote collection control
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- The prime security concern is preserving the confidentiality of usage
../data/rfc/rfc1272.txt- data. (See ISO 7498 Part 2, "Security Architecture," for security
../data/rfc/rfc1272.txt: terminology used herein.) Given that accounting data are sensitive,
../data/rfc/rfc1272.txt- the collector should be able (or may be required) to provide
../data/rfc/rfc1272.txt: confidentiality for accounting data at the point of collection,
../data/rfc/rfc1272.txt- through transmission and up to the point where the data is delivered.
../data/rfc/rfc1272.txt- The delivery function may also require authentication of the origin
../data/rfc/rfc1272.txt- and destination and provision for connection integrity (if
../data/rfc/rfc1272.txt- connections are utilized). Other security services (e.g., measures
../data/rfc/rfc1272.txt- to counter denial of service attacks) are not deemed necessary for
../data/rfc/rfc1272.txt: internet accounting at this time. It is assumed that security
../data/rfc/rfc1272.txt- services can be provided by SNMP and its mechanisms. (This will
../data/rfc/rfc1272.txt- require further investigation.)
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- In order to have an accurate monitoring system, reliable delivery of
../data/rfc/rfc1272.txt- data should be assured through one or more of:
--
../data/rfc/rfc1272.txt- There is a place for both application polling and meter traps within
../data/rfc/rfc1272.txt- this scheme, but there are significant trade-offs associated with
../data/rfc/rfc1272.txt- each.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- Polling means that the collection point has some control over when
../data/rfc/rfc1272.txt: accounting data is sent, so that not all meters flood the collector
../data/rfc/rfc1272.txt- at once. However, polling messages, particularly when structured
../data/rfc/rfc1272.txt- with SNMP's GET-NEXT operator, add considerable overhead to the
../data/rfc/rfc1272.txt- network. Meter traps are required in any case (whether or not
../data/rfc/rfc1272.txt- polling is the preferred collection method), so that a meter may rid
../data/rfc/rfc1272.txt- itself of data when its cache is full.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-Mills, Hirsh, & Ruth [Page 13]
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt:RFC 1272 Internet Accounting: Background November 1991
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- The fundamental collection trade-off will be between primary and
../data/rfc/rfc1272.txt- secondary storage at the meter, coupled with an efficient bulk-
../data/rfc/rfc1272.txt- transfer protocol, versus minimal storage at the meter and a
--
../data/rfc/rfc1272.txt- packets (e.g., in times of congestion when the router cannot handle
../data/rfc/rfc1272.txt- the offered load); it is presumed that higher level protocols (e.g.,
../data/rfc/rfc1272.txt- TCP) will provide whatever reliable delivery service the user deems
../data/rfc/rfc1272.txt- necessary (by detecting non- delivery and retransmitting).
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt: The question arises, therefore, whether an internet accounting system
../data/rfc/rfc1272.txt- should count all packets offered to a router (since each packet
../data/rfc/rfc1272.txt- offered consumes some router resources) or just those that are
../data/rfc/rfc1272.txt- finally passed by the router to a network (why should a user pay for
../data/rfc/rfc1272.txt- undelivered packets?) Since there are good arguments for either
../data/rfc/rfc1272.txt- position, we do not attempt to resolve this issue here. (It should
../data/rfc/rfc1272.txt- be noted, however, that SMDS has chosen to count on exit only.)
../data/rfc/rfc1272.txt: Rather, we require that an internet accounting should provide ability
../data/rfc/rfc1272.txt- for counting packets either way -- on entry to or on exit from a
../data/rfc/rfc1272.txt- router.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-5. Examples
../data/rfc/rfc1272.txt-
--
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-5.1 A Single Segment LAN
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- Consumers and providers on a single LAN service can utilize the same
../data/rfc/rfc1272.txt- set of data: the contribution of individual hosts to total network
../data/rfc/rfc1272.txt: load. A network accounting system measures flows between individual
../data/rfc/rfc1272.txt- host pairs. (On a broadcast LAN, e.g., an Ethernet, this can be
../data/rfc/rfc1272.txt- accomplished by a single meter placed anywhere on the LAN.) Using
../data/rfc/rfc1272.txt- this data, costs for the network management activity can be
../data/rfc/rfc1272.txt- apportioned to individual hosts or the departments that own/manage
../data/rfc/rfc1272.txt- the hosts.
--
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-Mills, Hirsh, & Ruth [Page 14]
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt:RFC 1272 Internet Accounting: Background November 1991
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-5.2 An Extended (Campus or Facility-Wide) LAN
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- 128.252.100.X 128.252.150.X 128.253.220.X
--
../data/rfc/rfc1272.txt- individual hosts on adjacent subnets are aggregated into a single
../data/rfc/rfc1272.txt- flow that measures activity between subnets.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- The service consumers, or subnets, might in turn want to keep track
../data/rfc/rfc1272.txt- of the communications between individual hosts that use the services
../data/rfc/rfc1272.txt: of the backbone. An accounting system on the backbone could be
../data/rfc/rfc1272.txt- configured to monitor traffic among individual host pairs.
../data/rfc/rfc1272.txt: Alternately an accounting system on each individual subnet could keep
../data/rfc/rfc1272.txt- track of local and "non-local" traffic. The observed data of the two
../data/rfc/rfc1272.txt- sets of meters (one for the service provider and one for the service
../data/rfc/rfc1272.txt- consumers) should have reconcilable data.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
--
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-Mills, Hirsh, & Ruth [Page 15]
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt:RFC 1272 Internet Accounting: Background November 1991
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-5.3 A Regional Network
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- 116.125
--
../data/rfc/rfc1272.txt- 124.110
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- In this example we have a regional network consisting of a ring of
../data/rfc/rfc1272.txt- point-to-point links that interconnect a collection of campus-wide
../data/rfc/rfc1272.txt- LANs. Again service provider and consumer have differing interests
../data/rfc/rfc1272.txt: and needs for accounting data. The service provider, the regional
../data/rfc/rfc1272.txt- network, again will be interested in the contribution of each
../data/rfc/rfc1272.txt- individual network to the total traffic on the regional network.
../data/rfc/rfc1272.txt- This interest might extend to include measure of individual link
../data/rfc/rfc1272.txt- utilization, and not just total offered load to the network as a
../data/rfc/rfc1272.txt- whole. In this latter case the service provider will require that
--
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-Mills, Hirsh, & Ruth [Page 16]
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt:RFC 1272 Internet Accounting: Background November 1991
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-5.4 A National Backbone
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- __________
--
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-Mills, Hirsh, & Ruth [Page 17]
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt:RFC 1272 Internet Accounting: Background November 1991
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- APPLICATIONS standards: Recommendations for storage, processing and
../data/rfc/rfc1272.txt- reporting are left out for the moment. Storage and processing of
../data/rfc/rfc1272.txt: accounting information is dependent on individual network policy.
../data/rfc/rfc1272.txt- Recommendations for standardizing billing schemes would be premature.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- QUOTAS are a form of closed loop feedback that represent an
../data/rfc/rfc1272.txt- interesting extension of usage reporting. But they will have to wait
../data/rfc/rfc1272.txt: until the basic accounting technology is reasonably defined and has
../data/rfc/rfc1272.txt- been the subject of a reasonable amount of experimentation.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt: SESSION ACCOUNTING: Detailed auditing of individual sessions across
../data/rfc/rfc1272.txt- the internet (at level four or higher) will not be addressed by
../data/rfc/rfc1272.txt: internet accounting. Internet accounting deals only with measuring
../data/rfc/rfc1272.txt- traffic at the IP level.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt: APPLICATION LEVEL ACCOUNTING: Service hosts and proxy agents have to
../data/rfc/rfc1272.txt: do their own accounting for services, since the network cannot
../data/rfc/rfc1272.txt- distinguish on whose behalf they are acting. Alternately, TCP/UDP
../data/rfc/rfc1272.txt- port numbers could become an optional field in a meter, since the
../data/rfc/rfc1272.txt- conjunction of a pair of IP addresses and port numbers occurring at a
../data/rfc/rfc1272.txt- particular time uniquely identifies a pair of communicating
../data/rfc/rfc1272.txt- processes.
--
../data/rfc/rfc1272.txt- probably contain two parts - a subscriber identification and a user
../data/rfc/rfc1272.txt- sub-identification - to allow for the later introduction of quota
../data/rfc/rfc1272.txt- mechanisms which have both group and individual quotas. The
../data/rfc/rfc1272.txt- subscriber is the fiscally responsible entity, for example the
../data/rfc/rfc1272.txt- manager of a research group. In any case, routers must be able to
../data/rfc/rfc1272.txt: fall back to accounting by host, since there will most certainly be
../data/rfc/rfc1272.txt- hosts on the network which do not implement a new IP option in a
../data/rfc/rfc1272.txt- timely fashion.
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-7. References
../data/rfc/rfc1272.txt-
--
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-Mills, Hirsh, & Ruth [Page 18]
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt:RFC 1272 Internet Accounting: Background November 1991
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt-Security Considerations
../data/rfc/rfc1272.txt-
../data/rfc/rfc1272.txt- Security issues are discussed in sections 2, 3 and 4.
--
../data/rfc/rfc4484.txt-
../data/rfc/rfc4484.txt-4.1. Settlement for Services
../data/rfc/rfc4484.txt-
../data/rfc/rfc4484.txt- When endpoints in two domains share real-time communications
../data/rfc/rfc4484.txt- services, sometimes there is a need for the domains to exchange
../data/rfc/rfc4484.txt: accounting and settlement information in real-time. The operators of
../data/rfc/rfc4484.txt- valuable resources (for example, Public Switched Telephone Network
../data/rfc/rfc4484.txt- (PSTN) trunking, conference bridges, or the like) in the called
../data/rfc/rfc4484.txt- domain may wish to settle with the calling domain (either with the
../data/rfc/rfc4484.txt: operators of the domain or a particular user), and some accounting
../data/rfc/rfc4484.txt- operations might need to complete before a call is terminated. For
../data/rfc/rfc4484.txt- example, a caller in one domain might want to access a conference
../data/rfc/rfc4484.txt- bridge in another domain, and the called domain might wish to settle
../data/rfc/rfc4484.txt- for the usage of the bridge with the calling domain. Or in a
../data/rfc/rfc4484.txt- wireless context, a roaming user might want to use services in a
../data/rfc/rfc4484.txt- visited network, and the visited network might need to understand how
../data/rfc/rfc4484.txt- to settle with the user's home network for these services.
../data/rfc/rfc4484.txt-
../data/rfc/rfc4484.txt- Assuming that the calling domain constitutes some sort of commercial
../data/rfc/rfc4484.txt: service capable of exchanging accounting information, the called
../data/rfc/rfc4484.txt- domain may want to verify that the remote user has a billable account
../data/rfc/rfc4484.txt- in good standing before allowing a remote user access to valuable
../data/rfc/rfc4484.txt- resources. Moreover, the called domain may need to discover the
../data/rfc/rfc4484.txt: network address of an accounting server and some basic information
../data/rfc/rfc4484.txt- about how to settle with it.
../data/rfc/rfc4484.txt-
../data/rfc/rfc4484.txt- An authorization assertion created by the calling domain could
../data/rfc/rfc4484.txt- provide the called domain with an assurance that a user's account can
../data/rfc/rfc4484.txt- settle for a particular service. In some cases, no further
../data/rfc/rfc4484.txt- information may be required to process a transaction, but if more
../data/rfc/rfc4484.txt: specific accounting data is needed, traits could also communicate the
../data/rfc/rfc4484.txt: network address of an accounting server, the settlement protocol that
../data/rfc/rfc4484.txt- should be used, and so on.
../data/rfc/rfc4484.txt-
../data/rfc/rfc4484.txt-4.2. Associating Gateways with Providers
../data/rfc/rfc4484.txt-
../data/rfc/rfc4484.txt- Imagine a case where a particular telephone service provider has
--
../data/rfc/rfc3479.txt-
../data/rfc/rfc3479.txt- Upon receipt of a Keepalive message with the FT Cork TLV and the FT
../data/rfc/rfc3479.txt- Protection TLV, an LSR SHOULD perform the following actions:
../data/rfc/rfc3479.txt-
../data/rfc/rfc3479.txt- - Process and secure any messages from the peer LSR that have
../data/rfc/rfc3479.txt: sequence numbers less than (accounting for wrap) that contained in
../data/rfc/rfc3479.txt- the FT Protection TLV on the Keepalive message.
../data/rfc/rfc3479.txt-
../data/rfc/rfc3479.txt- - Send a Keepalive message back to the peer containing the FT Cork
../data/rfc/rfc3479.txt- TLV and the FT ACK TLV specifying the FT ACK sequence number
../data/rfc/rfc3479.txt- equal to that in the original Keepalive message (i.e. ACKing all
--
../data/rfc/rfc770.txt- 2-71 2-107 AHHP Regular Messages [1,3]
../data/rfc/rfc770.txt- 72-150 110-226 Reserved
../data/rfc/rfc770.txt- 151 227 CHAOS Protocol
../data/rfc/rfc770.txt- 152 230 PARC Universal Protocol
../data/rfc/rfc770.txt- 153 231 TIP Status Reporting
../data/rfc/rfc770.txt: 154 232 TIP Accounting
../data/rfc/rfc770.txt- 155 233 Internet Protocol (regular traffic) [44]
../data/rfc/rfc770.txt- 156-158 234-236 Internet Protocol (experimental traffic) [44]
../data/rfc/rfc770.txt- 159-191 237-277 Measurements [28]
../data/rfc/rfc770.txt- 192-195 300-303 Message Switching Protocol [4,5]
../data/rfc/rfc770.txt- 196-255 304-377 Experimental Protocols
--
../data/rfc/rfc7360.txt- This document is an Experimental RFC.
../data/rfc/rfc7360.txt-
../data/rfc/rfc7360.txt- It contains one of several approaches to address known cryptographic
../data/rfc/rfc7360.txt- weaknesses of the RADIUS protocol, such as described in [RFC6614].
../data/rfc/rfc7360.txt- This specification does not fulfill all recommendations for an
../data/rfc/rfc7360.txt: Authentication, Authorization, and Accounting (AAA) transport profile
../data/rfc/rfc7360.txt- as per [RFC3539]; however, unlike [RFC6614], it is based on UDP and
../data/rfc/rfc7360.txt- therefore does not have head-of-line blocking issues.
../data/rfc/rfc7360.txt-
../data/rfc/rfc7360.txt-
../data/rfc/rfc7360.txt-
--
../data/rfc/rfc7360.txt- RADIUS/DTLS, and how it interacts with RADIUS/UDP.
../data/rfc/rfc7360.txt-
../data/rfc/rfc7360.txt-3.1. DTLS Port and Packet Types
../data/rfc/rfc7360.txt-
../data/rfc/rfc7360.txt- The default destination port number for RADIUS/DTLS is UDP/2083.
../data/rfc/rfc7360.txt: There are no separate ports for authentication, accounting, and
../data/rfc/rfc7360.txt- dynamic authorization changes. The source port is arbitrary. The
../data/rfc/rfc7360.txt- text in [RFC6614], Section 3.4, describes issues surrounding the use
../data/rfc/rfc7360.txt- of one port for multiple packet types. We recognize that
../data/rfc/rfc7360.txt- implementations may allow the use of RADIUS/DTLS over non-standard
../data/rfc/rfc7360.txt- ports. In that case, the references to UDP/2083 in this document
--
../data/rfc/rfc7360.txt- [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
../data/rfc/rfc7360.txt- "Remote Authentication Dial In User Service (RADIUS)",
../data/rfc/rfc7360.txt- RFC 2865, June 2000.
../data/rfc/rfc7360.txt-
../data/rfc/rfc7360.txt- [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
../data/rfc/rfc7360.txt: Accounting (AAA) Transport Profile", RFC 3539, June 2003.
../data/rfc/rfc7360.txt-
../data/rfc/rfc7360.txt- [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
../data/rfc/rfc7360.txt- "Transport Layer Security (TLS) Session Resumption
../data/rfc/rfc7360.txt- without Server-Side State", RFC 5077, January 2008.
../data/rfc/rfc7360.txt-
--
../data/rfc/rfc7360.txt-11.2. Informative References
../data/rfc/rfc7360.txt-
../data/rfc/rfc7360.txt- [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
../data/rfc/rfc7360.txt- April 1992.
../data/rfc/rfc7360.txt-
../data/rfc/rfc7360.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc7360.txt-
../data/rfc/rfc7360.txt- [RFC4107] Bellovin, S. and R. Housley, "Guidelines for
../data/rfc/rfc7360.txt- Cryptographic Key Management", BCP 107, RFC 4107, June
../data/rfc/rfc7360.txt- 2005.
../data/rfc/rfc7360.txt-
--
../data/rfc/rfc6943.txt- o Authorization: a protocol might match a resource name against some
../data/rfc/rfc6943.txt- policy. For example, it might look up an access control list
../data/rfc/rfc6943.txt- (ACL) and then look up the security principal's identifier (or a
../data/rfc/rfc6943.txt- surrogate for it) in that ACL.
../data/rfc/rfc6943.txt-
../data/rfc/rfc6943.txt: o Accounting: a system might create an accounting record for a
../data/rfc/rfc6943.txt- security principal's identifier or resource name, and then might
../data/rfc/rfc6943.txt- later need to match a presented identifier to (for example) add
../data/rfc/rfc6943.txt- new filtering rules based on the records in order to stop an
../data/rfc/rfc6943.txt- attack.
../data/rfc/rfc6943.txt-
--
../data/rfc/rfc2848.txt-
../data/rfc/rfc2848.txt- Conversely, if a historical request is made on the disposition of a
../data/rfc/rfc2848.txt- service, this should be done within a short time after the service
../data/rfc/rfc2848.txt- has completed; the Executive System is unlikely to store the results
../data/rfc/rfc2848.txt- of service requests for long; these will have been processed as AMA
../data/rfc/rfc2848.txt: (Automatic Message Accounting) records quickly, after which the
../data/rfc/rfc2848.txt- Executive System has no reason to keep them, and so they may be
../data/rfc/rfc2848.txt- discarded.
../data/rfc/rfc2848.txt-
../data/rfc/rfc2848.txt- Where the PINT Gateway and the Executive System are intimately
../data/rfc/rfc2848.txt- linked, the Gateway can respond to status subscription requests that
--
../data/rfc/rfc1820.txt- 2. System installation, configuration and management
../data/rfc/rfc1820.txt- 2.1 How complex/easy is installation and configuration? Are
../data/rfc/rfc1820.txt- there any pitfalls that need attention? Can you configure
../data/rfc/rfc1820.txt- per set of users (i.e systemwide or LAN wide default
../data/rfc/rfc1820.txt- configuration) and/or per user?
../data/rfc/rfc1820.txt: 2.2 Are there facilities for logging and/or accounting?
../data/rfc/rfc1820.txt- 2.3 Does the UA generate correct RFC 822 headers for outgoing
../data/rfc/rfc1820.txt- messages:
../data/rfc/rfc1820.txt- From:, (and if necessary) Sender:
../data/rfc/rfc1820.txt- Date:
../data/rfc/rfc1820.txt- Message-id:
--
../data/rfc/rfc5812.txt- associated with a packet. The vertical axis between the CE and the
../data/rfc/rfc5812.txt- FE denotes the Fp reference point where bidirectional communication
../data/rfc/rfc5812.txt- between the CE and FE occurs: the CE-to-FE communication is for
../data/rfc/rfc5812.txt- configuration, control, and packet injection, while the FE-to-CE
../data/rfc/rfc5812.txt- communication is used for packet redirection to the control plane,
../data/rfc/rfc5812.txt: reporting of monitoring and accounting information, reporting of
../data/rfc/rfc5812.txt- errors, etc. Note that the interaction between the CE and the LFB is
../data/rfc/rfc5812.txt- only abstract and indirect. The result of such an interaction is for
../data/rfc/rfc5812.txt- the CE to manipulate the components of the LFB instances.
../data/rfc/rfc5812.txt-
../data/rfc/rfc5812.txt- An LFB can have one or more inputs. Each input takes a pair of a
--
../data/rfc/rfc1287.txt- (IDRP) does this. BGP could evolve to do this. The additional
../data/rfc/rfc1287.txt- facility needed is a global table that maps network numbers to
../data/rfc/rfc1287.txt- ADs.
../data/rfc/rfc1287.txt-
../data/rfc/rfc1287.txt- For several reasons (special routes and address conversion, as
../data/rfc/rfc1287.txt: well as accounting and resource allocation), we are moving from a
../data/rfc/rfc1287.txt- "stateless" gateway model, where only precomputed routes are
../data/rfc/rfc1287.txt- stored in the gateway, to a model where at least some of the
../data/rfc/rfc1287.txt- gateways have per-connection state.
../data/rfc/rfc1287.txt-
../data/rfc/rfc1287.txt- 2.2 Extended IP Address Formats
--
../data/rfc/rfc1287.txt- distinct methods should be used inside and outside ADs
../data/rfc/rfc1287.txt- and aggregates.
../data/rfc/rfc1287.txt-
../data/rfc/rfc1287.txt- Existing projects planned for DARTnet will help resolve several of
../data/rfc/rfc1287.txt- these issues: state in gateways, state setup, address mapping,
../data/rfc/rfc1287.txt: accounting and so on. Other experiments in the R&D community also
../data/rfc/rfc1287.txt- bear on this area.
../data/rfc/rfc1287.txt-
../data/rfc/rfc1287.txt-3. MULTI-PROTOCOL ARCHITECTURE
../data/rfc/rfc1287.txt-
../data/rfc/rfc1287.txt- Changing the Internet to support multiple protocol suites leads to
--
../data/rfc/rfc1287.txt- Resource guarantees of whatever flavor must hold across an
../data/rfc/rfc1287.txt- arbitrary end-to-end path, including multiple ADs. Hence,
../data/rfc/rfc1287.txt- any resource setup mechanism needs to mesh smoothly with the
../data/rfc/rfc1287.txt- path setup mechanism incorporated into IDPR.
../data/rfc/rfc1287.txt-
../data/rfc/rfc1287.txt: o Accounting
../data/rfc/rfc1287.txt-
../data/rfc/rfc1287.txt- The resource guarantee subsets ("classes") may be natural
../data/rfc/rfc1287.txt: units for accounting.
../data/rfc/rfc1287.txt-
../data/rfc/rfc1287.txt- 5.3 Proposed Actions
../data/rfc/rfc1287.txt-
../data/rfc/rfc1287.txt- The actions called for here are further research on the technical
../data/rfc/rfc1287.txt- issues listed above, followed by development and standardization
--
../data/rfc/rfc1287.txt-
../data/rfc/rfc1287.txt- Getting big:
../data/rfc/rfc1287.txt- User services, what technology for host and nets?
../data/rfc/rfc1287.txt-
../data/rfc/rfc1287.txt- Divestiture of the Internet:
../data/rfc/rfc1287.txt: Accounting, controlling usage and fixing faults.
../data/rfc/rfc1287.txt-
../data/rfc/rfc1287.txt- New services:
../data/rfc/rfc1287.txt- Video? Transactions? Distributed computing?
../data/rfc/rfc1287.txt-
../data/rfc/rfc1287.txt- Security:
--
../data/rfc/rfc672.txt- Preface:
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt- This RFC reproduces most of a working document
../data/rfc/rfc672.txt- prepared during the design and implementation of the
../data/rfc/rfc672.txt- protocols for the TIP-TENEX integrated system for
../data/rfc/rfc672.txt: handling TIP accounting. Bernie Cosell (BBN-TIP)
../data/rfc/rfc672.txt- and Bob Thomas (BBN-TENEX) have contributed to
../data/rfc/rfc672.txt- various aspects of this work. The system has been
../data/rfc/rfc672.txt- partially operational for about a month on selected
../data/rfc/rfc672.txt- hosts. We feel that the techniques described here
../data/rfc/rfc672.txt: have wide applicability beyond TIP accounting.
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt-Section I
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt-Protocols for a Multi-site Data Collection Facility
--
../data/rfc/rfc672.txt-problem deals with providing a highly reliable data collection
../data/rfc/rfc672.txt-facility, by supporting it at many sites throughout the network. In
../data/rfc/rfc672.txt-the second section of this document, we describe in detail a
../data/rfc/rfc672.txt-particular implementation of the protocol which handles the problem
../data/rfc/rfc672.txt-of utilizing multiple data collector processes for collecting
../data/rfc/rfc672.txt:accounting data generated by the network TIPs. This example also
../data/rfc/rfc672.txt-illustrates the specialization of hosts to perform parts of a
../data/rfc/rfc672.txt-computation they are best equipped to handle. The large network
../data/rfc/rfc672.txt:hosts (TENEX systems) perform the accounting function for the small
../data/rfc/rfc672.txt-network access TiPs.
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt- The situation to be discussed is the following: a data
../data/rfc/rfc672.txt-generating process needs to use a data collection service which is
../data/rfc/rfc672.txt-duplicately provided by processes on a number of network machines.
--
../data/rfc/rfc672.txt-expense of possible duplication.
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt- Thus, the nature of the problem will dictate which of the
../data/rfc/rfc672.txt-protocols is appropriate for a given situation. The next section
../data/rfc/rfc672.txt-deals in the specifics of an implement;tion of a data collection
../data/rfc/rfc672.txt:protocol to handle the problem of collecting TIP accounting data by
../data/rfc/rfc672.txt-using the TENEX systems for running the collection server processes.
../data/rfc/rfc672.txt:It is shown how the general protocol is optimized for the accounting
../data/rfc/rfc672.txt-data collection.
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt-Section II
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt:Protocol for TIP-TENEX Accounting Server Information Exchange
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt-Overview of the Facility
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt-
--
../data/rfc/rfc672.txt-an authentication data base. The user must then complete s login
../data/rfc/rfc672.txt-sequence in order to authenticate himself. If he is successful the
../data/rfc/rfc672.txt-RSEXEC will transmit his unique ID code to the TIP. Failure will
../data/rfc/rfc672.txt-cause the RSEXEC to close the connection and the TIP to hang up on
../data/rfc/rfc672.txt-the user. After the user is authenticated, the TIP will accumulate
../data/rfc/rfc672.txt:accounting data for the user session. The data includes a count of
../data/rfc/rfc672.txt-messages sent on behalf of the user, and the connect time for the
../data/rfc/rfc672.txt-user. From time to time the TIP will transmit intermediate
../data/rfc/rfc672.txt:accounting data to Accounting Server (ACTSER) processes scattered
../data/rfc/rfc672.txt:throughout the network. These accounting servers will maintain
../data/rfc/rfc672.txt:files containing intermediate raw accounting data. The raw
../data/rfc/rfc672.txt:accounting data will periodically be collected and sorted to produce
../data/rfc/rfc672.txt:an accounting data base. Providing a number of accounting servers
../data/rfc/rfc672.txt-reduces the possibility of being unable to find a repository for the
../data/rfc/rfc672.txt-intermediate data, which otherwise would be lost due to buffering
../data/rfc/rfc672.txt:limitations in the TiPs. The multitude of accounting servers can
../data/rfc/rfc672.txt-also serve to reduce the load on the individual hosts providing this
../data/rfc/rfc672.txt-facility.
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt- -5-
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt-The rest of this document details the protocol that has been
../data/rfc/rfc672.txt:developed to ensure delivery of TIP accounting data to one of the
../data/rfc/rfc672.txt:available accounting servers for storage in the intermediate
../data/rfc/rfc672.txt:accounting files.
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt-Adapting the Protocol
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt:The TIP to Accounting Server data exchange uses a protocol that
../data/rfc/rfc672.txt-allows the TIP to select for data transmission one, some, or all
../data/rfc/rfc672.txt-server hosts either sequentially or in parallel, yet insures that
../data/rfc/rfc672.txt:the data that becomes part of the accounting file does not contain
../data/rfc/rfc672.txt-duplicate information. The protocol also minimizes the amount of
../data/rfc/rfc672.txt-data buffering that must be done by the limited capacity TiPs. The
../data/rfc/rfc672.txt-protocol is applicable to a wide class of data collection problems
../data/rfc/rfc672.txt-which use a number of data generators and collectors. The following
../data/rfc/rfc672.txt:describes how the protocol works for TIP accounting.
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt-Each TIP is responsible for maintaining in its memory the cells
../data/rfc/rfc672.txt-indicating the connect time and the number of messages sent for each
../data/rfc/rfc672.txt-of its current users. These cells are incremented by the TIP for
../data/rfc/rfc672.txt-every quantum of connect time and message sent, as the case may be.
../data/rfc/rfc672.txt-This is the data generation phase. Periodically, the TIP will scan
../data/rfc/rfc672.txt-all its active counters, and along with each user ID code, pack the
../data/rfc/rfc672.txt-accumulated data into one network message (i.e. less than 8K bits).
../data/rfc/rfc672.txt:The TIP then transmits this data to a set of Accounting Server
../data/rfc/rfc672.txt-processes residing throughout the network. The data transfer is
../data/rfc/rfc672.txt:over a specially designated host-host link. The accounting servers
../data/rfc/rfc672.txt-utilize the raw network message facility of TENEX 1.32 in order to
../data/rfc/rfc672.txt-directly access that link. When an ACTSER receives a data message
../data/rfc/rfc672.txt-from a TIP, it buffers the data and replies by returning the entire
../data/rfc/rfc672.txt-message to the originating TIP. The TIP responds with a positive
../data/rfc/rfc672.txt-acknowledgement ("go ahead") to the first ACTSER which returns the
--
../data/rfc/rfc672.txt-all subsequent ACTSER data return messages for this series of
../data/rfc/rfc672.txt-transfers. If the TIP does not receive a reply from any ACTSER, it
../data/rfc/rfc672.txt-accumulates new data (i.e. the TIP has all the while been
../data/rfc/rfc672.txt-incrementing its local counters to reflect the increased connect
../data/rfc/rfc672.txt-time and message count; the current values will comprise new data
../data/rfc/rfc672.txt:transfers) and sends the new data to the Accounting Server
../data/rfc/rfc672.txt-processes. When an ACTSER receives a positive acknowledgement from
../data/rfc/rfc672.txt-a TIP (i.e. "go ahead"), it appends the appropriate parts of the
../data/rfc/rfc672.txt:buffered data to the locally maintained accounting information file.
../data/rfc/rfc672.txt-On receiving a negative acknowledgement from the TIP (i.e.
../data/rfc/rfc672.txt-"discard"), the ACTSER discards the data buffered for this TIP. In
../data/rfc/rfc672.txt--addition, when the TIP responds with a "go ahead" to the first
../data/rfc/rfc672.txt-ACTSER which has accepted the data (acknowledged by returning the
../data/rfc/rfc672.txt-data along with the "I've got it"), the TIP decrements the connect
../data/rfc/rfc672.txt-time and message counters for each user by the amount indicated in
../data/rfc/rfc672.txt-the data returned by the ACTSER. This data will already be
../data/rfc/rfc672.txt:accounted for in the intermediate accounting files.
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt-As an aid in determining which ACTSER replies are to current
../data/rfc/rfc672.txt-requests, and which are tardy replies to old requests, the TIP
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt- -6-
--
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt-There are a number of points concerning the protocol that
../data/rfc/rfc672.txt-should be noted.
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt-1. The data generator (TIP) can send different (i.e. updated
../data/rfc/rfc672.txt:versions) data to different data collectors (accounting servers) as
../data/rfc/rfc672.txt-part of the same logical transmission sequence. This is possible
../data/rfc/rfc672.txt-because the TIP does not account for the data sent until it receives
../data/rfc/rfc672.txt-the acknowledgement of the data echo. This strategy relieves the
../data/rfc/rfc672.txt-TIP of any buffering in conjunction with re-transmission of data
../data/rfc/rfc672.txt-which hasn't been acknowledged.
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt:2. A new data request to an accounting server from a TIP will
../data/rfc/rfc672.txt-also serve as a negative acknowledgement concerning any data already
../data/rfc/rfc672.txt-buffered by the ACTSER for that TIP, but not yet acknowledged. The
../data/rfc/rfc672.txt-old data will be discarded, and the new data will be buffered and
../data/rfc/rfc672.txt-echoed as an acknowledgement. This allows the TIP the option of not
../data/rfc/rfc672.txt-sending a negative acknowledgement when it is not convenient to do
--
../data/rfc/rfc672.txt-This is to prevent a slow acknowledgement to the old data from being
../data/rfc/rfc672.txt-accepted by the TIP, after the TIP has already sent the new data to
../data/rfc/rfc672.txt-the slow host. This caveat can be avoided if the TIP does not
../data/rfc/rfc672.txt-resend to a non-responding server within the time period that a
../data/rfc/rfc672.txt-message could possibly be stuck in the network, but could still be
../data/rfc/rfc672.txt:delivered. Ignoring this situation may result in some accounting
../data/rfc/rfc672.txt-data being counted twice. Because of the rule to keep old data when
../data/rfc/rfc672.txt-confronted with matching sequence numbers, on restarting after a
../data/rfc/rfc672.txt-crash, the TIP should send a "discard" message to all servers in
../data/rfc/rfc672.txt-order to clear any data which has been buffered for it prior to the
../data/rfc/rfc672.txt-crash. An alternative to this would be for the TIP to initialize
../data/rfc/rfc672.txt-its sequence number from a varying source such as time of day.
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt:3. The accounting server similarly need not acknowledge receipt
../data/rfc/rfc672.txt-of data (by echoing) if it finds itself otherwise occupied. This
../data/rfc/rfc672.txt-will mean that the ACTSER is not buffering the data, and hence is
../data/rfc/rfc672.txt-not a candidate for entering the data into the file. However, the
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt- -7-
../data/rfc/rfc672.txt-TIP may try this ACTSER at a later time (even with the same data),
../data/rfc/rfc672.txt-with no ill effects.
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt-4. Because of 2 and 3 above, the protocol is robust with respect
../data/rfc/rfc672.txt:to lost or garbled transmissions of TIP data requests and accounting
../data/rfc/rfc672.txt-server echo replies. That is, in the event of loss of such a
../data/rfc/rfc672.txt-message, a re-transmission will occur as the normal procedure.
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt-5. There is no synchronization problem with respect to the
../data/rfc/rfc672.txt-sequence number used for duplicate detection, since this number is
../data/rfc/rfc672.txt:maintained only at the TIP site. The accounting server merely
../data/rfc/rfc672.txt-echoes the sequence number it has received as part of the data.
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt-6. There are, however, some constraints on the size of the
../data/rfc/rfc672.txt-sequence number field. It must be large enough so that ALL traces
../data/rfc/rfc672.txt-of the previous use of a given sequence number are totally reMoved
--
../data/rfc/rfc672.txt-number field (16 bits), and by allowing sufficient time between
../data/rfc/rfc672.txt-instances of sending new data, we can effectively reduce the
../data/rfc/rfc672.txt-probability of such an error to zero.
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt-7. Since the data involved in this problem is the source of
../data/rfc/rfc672.txt:accounting information, care must be taken to avoid duplicate
../data/rfc/rfc672.txt-entries. This must be done at the expense of potentially losing
../data/rfc/rfc672.txt-data in certain instances. Other than the obvious TIP malfunction,
../data/rfc/rfc672.txt-there are two known ways of losing data. One is the situation where
../data/rfc/rfc672.txt:no accounting server responds to a TIP for an extended period of
../data/rfc/rfc672.txt-time causing the TIP counters to overflow (highly unlikely if there
../data/rfc/rfc672.txt:are sufficient Accounting Servers). In this case, the TIP can hold
../data/rfc/rfc672.txt-the counters at their maximum value until a server comes up, thereby
../data/rfc/rfc672.txt:keeping the lost accounting data at its minimum. The other
../data/rfc/rfc672.txt-situation results from adapting the protocol to our insistence on no
../data/rfc/rfc672.txt-duplicate data in the incremental files. We are vulnerable to data
../data/rfc/rfc672.txt-loss with no recourse from the time the server receives the "go
../data/rfc/rfc672.txt-ahead" to update the file with the buffered data (i.e. positive
../data/rfc/rfc672.txt-acknowledgement) until the time the update is completed and the file
../data/rfc/rfc672.txt:is closed. An accounting server crash during this period will cause
../data/rfc/rfc672.txt:that accounting data to be lost. In our initial implementation, we
../data/rfc/rfc672.txt-have slightly extended this period of vulnerability in order to save
../data/rfc/rfc672.txt-the TIP from having to buffer the acknowledged data for a short
../data/rfc/rfc672.txt-period of time. By updating TIP counters from the returned data in
../data/rfc/rfc672.txt-parallel with sending the "go ahead" acknowledgement, we relieve the
../data/rfc/rfc672.txt-TIP of the burden of buffering this data until the Request for Next
../data/rfc/rfc672.txt:Message (RFNM) from the accounting server IMP is received. This
../data/rfc/rfc672.txt-adds slightly to our period of vulnerability to malfunction, moving
../data/rfc/rfc672.txt-the beginning of the period from the point when the ACTSER host
../data/rfc/rfc672.txt-receives the "go ahead", back to the point when the TIP sends off
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt- -8-
--
../data/rfc/rfc672.txt-acknowledgement before updating its counters. In such a case, if
../data/rfc/rfc672.txt-the RFNM does not come, the TIP can discard the buffered data and
../data/rfc/rfc672.txt-re-transmit new data to other servers.
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt-8. There is adequate protection against the entry of forged data
../data/rfc/rfc672.txt:into the intermediate accounting files. This is primarily due to
../data/rfc/rfc672.txt-the system enforced limited access to Host-Imp messages and
../data/rfc/rfc672.txt-Host-Host links. In addition, messages received on such designated
../data/rfc/rfc672.txt-limited access links can be easily verified as coming from a TIP.
../data/rfc/rfc672.txt-The IMP subnet appends the signature (address) of the sending host
../data/rfc/rfc672.txt:to all of its messages, so there can be no forging. The Accounting
../data/rfc/rfc672.txt-Server is in a position to check if the source of the message is in
../data/rfc/rfc672.txt-fact a TIP data generator.
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt-Current Parameters of the Protocol
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt-
../data/rfc/rfc672.txt-In the initial implementation, the TIP sends its accumulated
../data/rfc/rfc672.txt:accounting data about once every half hour. If it gets no positive
../data/rfc/rfc672.txt-acknowledgement, it tries to send with greater frequency (about
../data/rfc/rfc672.txt-every 5 minutes) until it finally succeeds. It can then return to
../data/rfc/rfc672.txt-the normal waiting period. (A TIP user logout introduces an
../data/rfc/rfc672.txt-exception to this behavior. In order to re-use the TIP port and its
../data/rfc/rfc672.txt-associated counters as soon as possible, a user terminating his TIP
../data/rfc/rfc672.txt:session causes the accounting data to be sent immediately).
../data/rfc/rfc672.txt-initially, our implementation calls for each TIP to remember a
../data/rfc/rfc672.txt:"favored" accounting server. At the wait period expiration, the TIP
../data/rfc/rfc672.txt-will try to deposit the data at its "favored" site. If successful
../data/rfc/rfc672.txt-within a short timeout period, this site remains the favored site,
../data/rfc/rfc672.txt-and the wait interval is reset. If unsuccessful within the short
../data/rfc/rfc672.txt-timeout, the data can be sent to all servers*. The one replying
../data/rfc/rfc672.txt-first will update its file with the data and also become the
--
../data/rfc/rfc5982.txt- o Measurement system capacity: This consists of the bandwidth of the
../data/rfc/rfc5982.txt- management network, the storage capacity, and the performances of
../data/rfc/rfc5982.txt- the collecting devices and exporting devices.
../data/rfc/rfc5982.txt-
../data/rfc/rfc5982.txt- o Application requirements: Different applications, such as traffic
../data/rfc/rfc5982.txt: engineering, detecting traffic anomalies, and accounting, impose
../data/rfc/rfc5982.txt- different Flow Record granularities, and data accuracies.
../data/rfc/rfc5982.txt-
../data/rfc/rfc5982.txt- The sustained growth of IP traffic has been overwhelming the
../data/rfc/rfc5982.txt- capacities of measurement systems. Furthermore, a large variety of
../data/rfc/rfc5982.txt- applications (e.g., Quality-of-Service (QoS) measurement, traffic
--
../data/rfc/rfc2138.txt-1. Introduction
../data/rfc/rfc2138.txt-
../data/rfc/rfc2138.txt- Managing dispersed serial line and modem pools for large numbers of
../data/rfc/rfc2138.txt- users can create the need for significant administrative support.
../data/rfc/rfc2138.txt- Since modem pools are by definition a link to the outside world, they
../data/rfc/rfc2138.txt: require careful attention to security, authorization and accounting.
../data/rfc/rfc2138.txt- This can be best achieved by managing a single "database" of users,
../data/rfc/rfc2138.txt- which allows for authentication (verifying user name and password) as
../data/rfc/rfc2138.txt- well as configuration information detailing the type of service to
../data/rfc/rfc2138.txt- deliver to the user (for example, SLIP, PPP, telnet, rlogin).
../data/rfc/rfc2138.txt-
--
../data/rfc/rfc2138.txt- RADIUS Codes (decimal) are assigned as follows:
../data/rfc/rfc2138.txt-
../data/rfc/rfc2138.txt- 1 Access-Request
../data/rfc/rfc2138.txt- 2 Access-Accept
../data/rfc/rfc2138.txt- 3 Access-Reject
../data/rfc/rfc2138.txt: 4 Accounting-Request
../data/rfc/rfc2138.txt: 5 Accounting-Response
../data/rfc/rfc2138.txt- 11 Access-Challenge
../data/rfc/rfc2138.txt- 12 Status-Server (experimental)
../data/rfc/rfc2138.txt- 13 Status-Client (experimental)
../data/rfc/rfc2138.txt- 255 Reserved
../data/rfc/rfc2138.txt-
--
../data/rfc/rfc2138.txt-Rigney, et. al. Standards Track [Page 10]
../data/rfc/rfc2138.txt-
../data/rfc/rfc2138.txt-RFC 2138 RADIUS April 1997
../data/rfc/rfc2138.txt-
../data/rfc/rfc2138.txt-
../data/rfc/rfc2138.txt: Codes 4 and 5 are covered in the RADIUS Accounting document [9], and
../data/rfc/rfc2138.txt- are not further mentioned here. Codes 12 and 13 are reserved for
../data/rfc/rfc2138.txt- possible use, but are not further mentioned here.
../data/rfc/rfc2138.txt-
../data/rfc/rfc2138.txt-Identifier
../data/rfc/rfc2138.txt-
--
../data/rfc/rfc2138.txt- In the section below on "Attributes" where the text refers to which
../data/rfc/rfc2138.txt- packets an attribute is allowed in, only packets with Codes 1, 2, 3
../data/rfc/rfc2138.txt- and 11 and attributes defined in this document are covered in this
../data/rfc/rfc2138.txt- document. A summary table is provided at the end of the "Attributes"
../data/rfc/rfc2138.txt- section. To determine which Attributes are allowed in packets with
../data/rfc/rfc2138.txt: codes 4 and 5 refer to the RADIUS Accounting document [9].
../data/rfc/rfc2138.txt-
../data/rfc/rfc2138.txt-4. Packet Types
../data/rfc/rfc2138.txt-
../data/rfc/rfc2138.txt- The RADIUS Packet type is determined by the Code field in the first
../data/rfc/rfc2138.txt- octet of the Packet.
--
../data/rfc/rfc2138.txt- 35 Login-LAT-Node
../data/rfc/rfc2138.txt- 36 Login-LAT-Group
../data/rfc/rfc2138.txt- 37 Framed-AppleTalk-Link
../data/rfc/rfc2138.txt- 38 Framed-AppleTalk-Network
../data/rfc/rfc2138.txt- 39 Framed-AppleTalk-Zone
../data/rfc/rfc2138.txt: 40-59 (reserved for accounting)
../data/rfc/rfc2138.txt- 60 CHAP-Challenge
../data/rfc/rfc2138.txt- 61 NAS-Port-Type
../data/rfc/rfc2138.txt- 62 Port-Limit
../data/rfc/rfc2138.txt- 63 Login-LAT-Port
../data/rfc/rfc2138.txt-
--
../data/rfc/rfc2138.txt-
../data/rfc/rfc2138.txt- Description
../data/rfc/rfc2138.txt-
../data/rfc/rfc2138.txt- This Attribute is available to be sent by the server to the client
../data/rfc/rfc2138.txt- in an Access-Accept and should be sent unmodified by the client to
../data/rfc/rfc2138.txt: the accounting server as part of the Accounting-Request packet if
../data/rfc/rfc2138.txt: accounting is supported. No interpretation by the client should
../data/rfc/rfc2138.txt- be made.
../data/rfc/rfc2138.txt-
../data/rfc/rfc2138.txt-
../data/rfc/rfc2138.txt-
../data/rfc/rfc2138.txt-
--
../data/rfc/rfc2138.txt- [8] Galvin, J., McCloghrie, K., and Davin, J., "SNMP Security
../data/rfc/rfc2138.txt- Protocols", RFC 1352, Trusted Information Systems, Inc., Hughes
../data/rfc/rfc2138.txt- LAN Systems, Inc., MIT Laboratory for Computer Science, July
../data/rfc/rfc2138.txt- 1992.
../data/rfc/rfc2138.txt-
../data/rfc/rfc2138.txt: [9] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
../data/rfc/rfc2138.txt-
../data/rfc/rfc2138.txt-Acknowledgments
../data/rfc/rfc2138.txt-
../data/rfc/rfc2138.txt- RADIUS was originally developed by Livingston Enterprises for their
../data/rfc/rfc2138.txt- PortMaster series of Network Access Servers.
--
../data/rfc/rfc2720.txt-
../data/rfc/rfc2720.txt-3 Overview
../data/rfc/rfc2720.txt-
../data/rfc/rfc2720.txt- Traffic Flow Measurement seeks to provide a well-defined method for
../data/rfc/rfc2720.txt- gathering traffic flow information from networks and internetworks.
../data/rfc/rfc2720.txt: The background for this is given in "Internet Accounting Background"
../data/rfc/rfc2720.txt- [ACT-BKG]. The Realtime Traffic Flow Measurement (rtfm) Working Group
../data/rfc/rfc2720.txt- has produced a measurement architecture to achieve this goal; this is
../data/rfc/rfc2720.txt- documented in "Traffic Flow Measurement: Architecture" [RTFM-ARC].
../data/rfc/rfc2720.txt- The architecture defines three entities:
../data/rfc/rfc2720.txt-
--
../data/rfc/rfc2720.txt- - METER READERS, which collect traffic flow data from meters, and
../data/rfc/rfc2720.txt-
../data/rfc/rfc2720.txt- - MANAGERS, which oversee the operation of meters and meter readers.
../data/rfc/rfc2720.txt-
../data/rfc/rfc2720.txt- This memo defines the SNMP management information for a Traffic Flow
../data/rfc/rfc2720.txt: Meter (TFM). Work in this field was begun by the Internet Accounting
../data/rfc/rfc2720.txt- Working Group. It has been further developed and expanded by the
../data/rfc/rfc2720.txt- Realtime Traffic Flow Measurement Working Group.
../data/rfc/rfc2720.txt-
../data/rfc/rfc2720.txt-
../data/rfc/rfc2720.txt-
--
../data/rfc/rfc2720.txt- STATUS current
../data/rfc/rfc2720.txt- DESCRIPTION
../data/rfc/rfc2720.txt- "Session ID for this flow. Such an ID might be allocated
../data/rfc/rfc2720.txt- by a network access server to distinguish a series of sessions
../data/rfc/rfc2720.txt- between the same pair of addresses, which would otherwise
../data/rfc/rfc2720.txt: appear to be parts of the same accounting flow."
../data/rfc/rfc2720.txt- ::= { flowDataEntry 35 }
../data/rfc/rfc2720.txt-
../data/rfc/rfc2720.txt-flowDataSourceClass OBJECT-TYPE
../data/rfc/rfc2720.txt- SYNTAX Integer32 (1..255)
../data/rfc/rfc2720.txt- MAX-ACCESS read-only
--
../data/rfc/rfc2720.txt- flowInactivityTimeout, flowActiveFlows,
../data/rfc/rfc2720.txt- flowMaxFlows, flowFloodMode }
../data/rfc/rfc2720.txt- STATUS deprecated
../data/rfc/rfc2720.txt- DESCRIPTION
../data/rfc/rfc2720.txt- "The control group defines objects which are used to control
../data/rfc/rfc2720.txt: an accounting meter."
../data/rfc/rfc2720.txt- ::= {flowMIBGroups 1 }
../data/rfc/rfc2720.txt-
../data/rfc/rfc2720.txt-flowDataTableGroup OBJECT-GROUP
../data/rfc/rfc2720.txt-
../data/rfc/rfc2720.txt-
--
../data/rfc/rfc2720.txt- flowInactivityTimeout, flowActiveFlows,
../data/rfc/rfc2720.txt- flowMaxFlows, flowFloodMode }
../data/rfc/rfc2720.txt- STATUS current
../data/rfc/rfc2720.txt- DESCRIPTION
../data/rfc/rfc2720.txt- "The control group defines objects which are used to control
../data/rfc/rfc2720.txt: an accounting meter. It replaces the earlier version of
../data/rfc/rfc2720.txt- flowControlGroup above (now deprecated)."
../data/rfc/rfc2720.txt- ::= {flowMIBGroups 9 }
../data/rfc/rfc2720.txt-
../data/rfc/rfc2720.txt-flowMIBCompliance MODULE-COMPLIANCE
../data/rfc/rfc2720.txt- STATUS current
--
../data/rfc/rfc2720.txt-
../data/rfc/rfc2720.txt-
../data/rfc/rfc2720.txt-8 Acknowledgements
../data/rfc/rfc2720.txt-
../data/rfc/rfc2720.txt- An early draft of this document was produced under the auspices of
../data/rfc/rfc2720.txt: the IETF's Accounting Working Group with assistance from the SNMP
../data/rfc/rfc2720.txt- Working Group and the Security Area Advisory Group. Particular
../data/rfc/rfc2720.txt- thanks are due to Jim Barnes, Sig Handelman and Stephen Stibler for
../data/rfc/rfc2720.txt- their support and their assistance with checking early versions of
../data/rfc/rfc2720.txt- the MIB.
../data/rfc/rfc2720.txt-
--
../data/rfc/rfc2720.txt- this standard. Please address the information to the IETF Executive
../data/rfc/rfc2720.txt- Director.
../data/rfc/rfc2720.txt-
../data/rfc/rfc2720.txt-10 References
../data/rfc/rfc2720.txt-
../data/rfc/rfc2720.txt: [ACT-BKG] Mills, C., Hirsch, G. and G. Ruth, "Internet Accounting
../data/rfc/rfc2720.txt- Background", RFC 1272, November 1991.
../data/rfc/rfc2720.txt-
../data/rfc/rfc2720.txt- [ASG-NBR] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
../data/rfc/rfc2720.txt- RFC 1700, ISI, October 1994.
../data/rfc/rfc2720.txt-
--
../data/rfc/rfc7155.txt- Diameter Network Access Server Application
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-Abstract
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- This document describes the Diameter protocol application used for
../data/rfc/rfc7155.txt: Authentication, Authorization, and Accounting services in the Network
../data/rfc/rfc7155.txt- Access Server (NAS) environment; it obsoletes RFC 4005. When
../data/rfc/rfc7155.txt- combined with the Diameter Base protocol, Transport Profile, and
../data/rfc/rfc7155.txt- Extensible Authentication Protocol specifications, this application
../data/rfc/rfc7155.txt- specification satisfies typical network access services requirements.
../data/rfc/rfc7155.txt-
--
../data/rfc/rfc7155.txt- 1.1. Changes from RFC 4005 ......................................5
../data/rfc/rfc7155.txt- 1.2. Terminology ................................................6
../data/rfc/rfc7155.txt- 1.3. Requirements Language ......................................7
../data/rfc/rfc7155.txt- 1.4. Advertising Application Support ............................8
../data/rfc/rfc7155.txt- 1.5. Application Identification .................................8
../data/rfc/rfc7155.txt: 1.6. Accounting Model ...........................................8
../data/rfc/rfc7155.txt- 2. NAS Calls, Ports, and Sessions ..................................8
../data/rfc/rfc7155.txt- 2.1. Diameter Session Establishment .............................9
../data/rfc/rfc7155.txt- 2.2. Diameter Session Reauthentication or Reauthorization .......9
../data/rfc/rfc7155.txt- 2.3. Diameter Session Termination ..............................10
../data/rfc/rfc7155.txt- 3. Diameter NAS Application Messages ..............................11
--
../data/rfc/rfc7155.txt- 3.4. Re-Auth-Answer (RAA) Command ..............................16
../data/rfc/rfc7155.txt- 3.5. Session-Termination-Request (STR) Command .................17
../data/rfc/rfc7155.txt- 3.6. Session-Termination-Answer (STA) Command ..................17
../data/rfc/rfc7155.txt- 3.7. Abort-Session-Request (ASR) Command .......................18
../data/rfc/rfc7155.txt- 3.8. Abort-Session-Answer (ASA) Command ........................19
../data/rfc/rfc7155.txt: 3.9. Accounting-Request (ACR) Command ..........................20
../data/rfc/rfc7155.txt: 3.10. Accounting-Answer (ACA) Command ..........................22
../data/rfc/rfc7155.txt- 4. Diameter NAS Application AVPs ..................................23
../data/rfc/rfc7155.txt- 4.1. Derived AVP Data Formats ..................................23
../data/rfc/rfc7155.txt- 4.1.1. QoSFilterRule ......................................23
../data/rfc/rfc7155.txt- 4.2. NAS Session AVPs ..........................................24
../data/rfc/rfc7155.txt- 4.2.1. Call and Session Information .......................24
--
../data/rfc/rfc7155.txt- 4.5.7. Tunnel-Private-Group-Id AVP ........................48
../data/rfc/rfc7155.txt- 4.5.8. Tunnel-Assignment-Id AVP ...........................48
../data/rfc/rfc7155.txt- 4.5.9. Tunnel-Preference AVP ..............................50
../data/rfc/rfc7155.txt- 4.5.10. Tunnel-Client-Auth-Id AVP .........................50
../data/rfc/rfc7155.txt- 4.5.11. Tunnel-Server-Auth-Id AVP .........................50
../data/rfc/rfc7155.txt: 4.6. NAS Accounting AVPs .......................................51
../data/rfc/rfc7155.txt: 4.6.1. Accounting-Input-Octets AVP ........................52
../data/rfc/rfc7155.txt: 4.6.2. Accounting-Output-Octets AVP .......................52
../data/rfc/rfc7155.txt: 4.6.3. Accounting-Input-Packets AVP .......................52
../data/rfc/rfc7155.txt: 4.6.4. Accounting-Output-Packets AVP ......................53
../data/rfc/rfc7155.txt- 4.6.5. Acct-Session-Time AVP ..............................53
../data/rfc/rfc7155.txt- 4.6.6. Acct-Authentic AVP .................................53
../data/rfc/rfc7155.txt: 4.6.7. Accounting-Auth-Method AVP .........................53
../data/rfc/rfc7155.txt- 4.6.8. Acct-Delay-Time AVP ................................53
../data/rfc/rfc7155.txt- 4.6.9. Acct-Link-Count AVP ................................54
../data/rfc/rfc7155.txt- 4.6.10. Acct-Tunnel-Connection AVP ........................55
../data/rfc/rfc7155.txt- 4.6.11. Acct-Tunnel-Packets-Lost AVP ......................55
../data/rfc/rfc7155.txt- 5. AVP Occurrence Tables ..........................................55
../data/rfc/rfc7155.txt- 5.1. AA-Request / AA-Answer AVP Table ..........................56
../data/rfc/rfc7155.txt: 5.2. Accounting AVP Tables .....................................58
../data/rfc/rfc7155.txt: 5.2.1. Framed Access Accounting AVP Table .................59
../data/rfc/rfc7155.txt: 5.2.2. Non-Framed Access Accounting AVP Table .............61
../data/rfc/rfc7155.txt- 6. Unicode Considerations .........................................62
../data/rfc/rfc7155.txt- 7. IANA Considerations ............................................63
../data/rfc/rfc7155.txt- 8. Security Considerations ........................................63
../data/rfc/rfc7155.txt- 8.1. Authentication Considerations .............................63
../data/rfc/rfc7155.txt- 8.2. AVP Considerations ........................................64
--
../data/rfc/rfc7155.txt- A.2. RFC 4005 ...................................................69
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-1. Introduction
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- This document describes the Diameter protocol application used for
../data/rfc/rfc7155.txt: Authentication, Authorization, and Accounting in the Network Access
../data/rfc/rfc7155.txt- Server (NAS) environment. When combined with the Diameter Base
../data/rfc/rfc7155.txt- protocol [RFC6733], Transport Profile [RFC3539], and Extensible
../data/rfc/rfc7155.txt- Authentication Protocol (EAP) [RFC4072] specifications, this
../data/rfc/rfc7155.txt- specification satisfies the NAS-related requirements defined in
../data/rfc/rfc7155.txt- [RFC2989] and [RFC3169].
--
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- First, this document describes the operation of a Diameter NAS
../data/rfc/rfc7155.txt- application. Then, it defines the Diameter message command codes.
../data/rfc/rfc7155.txt- The following sections list the AVPs used in these messages, grouped
../data/rfc/rfc7155.txt- by common usage. These are session identification, authentication,
../data/rfc/rfc7155.txt: authorization, tunneling, and accounting. The authorization AVPs are
../data/rfc/rfc7155.txt- further broken down by service type.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-1.1. Changes from RFC 4005
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- This document obsoletes [RFC4005] and is not backward compatible with
--
../data/rfc/rfc7155.txt- o All of the material regarding RADIUS/Diameter protocol
../data/rfc/rfc7155.txt- interactions has been removed; however, where AVPs are derived
../data/rfc/rfc7155.txt- from RADIUS Attributes, the range and format of those Attribute
../data/rfc/rfc7155.txt- values have been retained for ease of transition.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt: o The Command Code Format (CCF) [RFC6733] for the Accounting-Request
../data/rfc/rfc7155.txt: and Accounting-Answer messages has been changed to explicitly
../data/rfc/rfc7155.txt- require the inclusion of the Acct-Application-Id AVP and exclude
../data/rfc/rfc7155.txt- the Vendor-Specific-Application-Id AVP. Normally, this type of
../data/rfc/rfc7155.txt- change would require the allocation of a new command code (see
../data/rfc/rfc7155.txt- Section 1.3.3 of [RFC6733]) and consequently, a new application-
../data/rfc/rfc7155.txt- id. However, the presence of an instance of the Acct-Application-
../data/rfc/rfc7155.txt- Id AVP was required in [RFC4005], as well:
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt: The Accounting-Request (ACR) message [BASE] is sent by the NAS
../data/rfc/rfc7155.txt- to report its session information to a target server
../data/rfc/rfc7155.txt- downstream.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- Either the Acct-Application-Id or the Vendor-Specific-
../data/rfc/rfc7155.txt- Application-Id AVP MUST be present. If the Vendor-Specific-
--
../data/rfc/rfc7155.txt- longer be contained in the Vendor-Specific-Application-Id AVP).
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- o The lists of RADIUS attribute values have been deleted in favor of
../data/rfc/rfc7155.txt- references to the appropriate IANA registries.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt: o The accounting model to be used is now specified (see
../data/rfc/rfc7155.txt- Section 1.6).
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-
--
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- o Session-Termination-Request (Section 3.5)
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- o Abort-Session-Request (Section 3.7)
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt:1.6. Accounting Model
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt: It is RECOMMENDED that the coupled accounting model (RFC 6733,
../data/rfc/rfc7155.txt- Section 9.3) be used with this application; therefore, the value of
../data/rfc/rfc7155.txt: the Acct-Application-Id AVP in the Accounting-Request (Section 3.9)
../data/rfc/rfc7155.txt: and Accounting-Answer (Section 3.10) messages SHOULD be set to one
../data/rfc/rfc7155.txt- (1).
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-2. NAS Calls, Ports, and Sessions
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- The arrival of a new call or service connection at a port of a
--
../data/rfc/rfc7155.txt- When the authentication or authorization exchange completes
../data/rfc/rfc7155.txt- successfully, the NAS application SHOULD start a session context. If
../data/rfc/rfc7155.txt- the Result-Code of DIAMETER_MULTI_ROUND_AUTH is returned, the
../data/rfc/rfc7155.txt- exchange continues until a success or error is returned.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt: If accounting is active, the application MUST also send an Accounting
../data/rfc/rfc7155.txt: message [RFC6733]. An Accounting-Record-Type of START_RECORD is sent
../data/rfc/rfc7155.txt- for a new session. If a session fails to start, the EVENT_RECORD
../data/rfc/rfc7155.txt- message is sent with the reason for the failure described.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt: Note that the return of an unsupportable Accounting-Realtime-Required
../data/rfc/rfc7155.txt- value [RFC6733] would result in a failure to establish the session.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-2.2. Diameter Session Reauthentication or Reauthorization
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- The Diameter Base protocol allows users to be periodically
--
../data/rfc/rfc7155.txt-Zorn Standards Track [Page 9]
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-RFC 7155 Diameter NASREQ April 2014
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt: If accounting is active, every change of authentication or
../data/rfc/rfc7155.txt: authorization SHOULD generate an accounting message. If the NAS
../data/rfc/rfc7155.txt- service is a continuation of the prior user context, then an
../data/rfc/rfc7155.txt: Accounting-Record-Type of INTERIM_RECORD indicating the new session
../data/rfc/rfc7155.txt- attributes and cumulative status would be appropriate. If a new user
../data/rfc/rfc7155.txt- or a significant change in authorization is detected by the NAS, then
../data/rfc/rfc7155.txt- the service may send two messages of the types STOP_RECORD and
../data/rfc/rfc7155.txt: START_RECORD. Accounting may change the subsession identifiers
../data/rfc/rfc7155.txt- (Acct-Session-Id, or Acct-Sub-Session-Id) to indicate such
../data/rfc/rfc7155.txt- subsessions. A service may also use a different Session-Id value for
../data/rfc/rfc7155.txt: accounting (see Section 9.6 of [RFC6733]).
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- However, the Diameter Session-Id AVP value used for the initial
../data/rfc/rfc7155.txt- authorization exchange MUST be used to generate an STR message when
../data/rfc/rfc7155.txt- the session context is terminated.
../data/rfc/rfc7155.txt-
--
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- Furthermore, a NAS that receives an Abort-Session-Request (ASR)
../data/rfc/rfc7155.txt- [RFC6733] MUST issue an Abort-Session-Answer (ASA) if the session
../data/rfc/rfc7155.txt- identified is active and disconnect the PPP (or tunneling) session.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt: If accounting is active, an Accounting STOP_RECORD message [RFC6733]
../data/rfc/rfc7155.txt- MUST be sent upon termination of the session context.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- More information on Diameter Session Termination can be found in
../data/rfc/rfc7155.txt- Sections 8.4 and 8.5 of [RFC6733].
../data/rfc/rfc7155.txt-
--
../data/rfc/rfc7155.txt- | Re-Auth-Answer | RAA | 258 | Section 3.4 |
../data/rfc/rfc7155.txt- | Session-Termination-Request | STR | 275 | Section 3.5 |
../data/rfc/rfc7155.txt- | Session-Termination-Answer | STA | 275 | Section 3.6 |
../data/rfc/rfc7155.txt- | Abort-Session-Request | ASR | 274 | Section 3.7 |
../data/rfc/rfc7155.txt- | Abort-Session-Answer | ASA | 274 | Section 3.8 |
../data/rfc/rfc7155.txt: | Accounting-Request | ACR | 271 | Section 3.9 |
../data/rfc/rfc7155.txt: | Accounting-Answer | ACA | 271 | Section 3.10 |
../data/rfc/rfc7155.txt- +-----------------------------------+---------+------+--------------+
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- Note that the message formats in the following subsections use the
../data/rfc/rfc7155.txt- standard Diameter Command Code Format ([RFC6733], Section 3.2).
../data/rfc/rfc7155.txt-
--
../data/rfc/rfc7155.txt-Zorn Standards Track [Page 19]
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-RFC 7155 Diameter NASREQ April 2014
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt:3.9. Accounting-Request (ACR) Command
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- The ACR message [RFC6733] is sent by the NAS to report its session
../data/rfc/rfc7155.txt- information to a target server downstream.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- The Acct-Application-Id AVP MUST be present.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- The AVPs listed in the Diameter Base protocol specification [RFC6733]
../data/rfc/rfc7155.txt- MUST be assumed to be present, as appropriate. NAS service-specific
../data/rfc/rfc7155.txt: accounting AVPs SHOULD be present as described in Section 4.6 and the
../data/rfc/rfc7155.txt- rest of this specification.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- Message Format
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- <AC-Request> ::= < Diameter Header: 271, REQ, PXY >
../data/rfc/rfc7155.txt- < Session-Id >
../data/rfc/rfc7155.txt- { Origin-Host }
../data/rfc/rfc7155.txt- { Origin-Realm }
../data/rfc/rfc7155.txt- { Destination-Realm }
../data/rfc/rfc7155.txt: { Accounting-Record-Type }
../data/rfc/rfc7155.txt: { Accounting-Record-Number }
../data/rfc/rfc7155.txt- { Acct-Application-Id }
../data/rfc/rfc7155.txt- [ User-Name ]
../data/rfc/rfc7155.txt: [ Accounting-Sub-Session-Id ]
../data/rfc/rfc7155.txt- [ Acct-Session-Id ]
../data/rfc/rfc7155.txt- [ Acct-Multi-Session-Id ]
../data/rfc/rfc7155.txt- [ Origin-AAA-Protocol ]
../data/rfc/rfc7155.txt- [ Origin-State-Id ]
../data/rfc/rfc7155.txt- [ Destination-Host ]
--
../data/rfc/rfc7155.txt- [ NAS-Port-Id ]
../data/rfc/rfc7155.txt- [ NAS-Port-Type ]
../data/rfc/rfc7155.txt- * [ Class ]
../data/rfc/rfc7155.txt- [ Service-Type ]
../data/rfc/rfc7155.txt- [ Termination-Cause ]
../data/rfc/rfc7155.txt: [ Accounting-Input-Octets ]
../data/rfc/rfc7155.txt: [ Accounting-Input-Packets ]
../data/rfc/rfc7155.txt: [ Accounting-Output-Octets ]
../data/rfc/rfc7155.txt: [ Accounting-Output-Packets ]
../data/rfc/rfc7155.txt- [ Acct-Authentic ]
../data/rfc/rfc7155.txt: [ Accounting-Auth-Method ]
../data/rfc/rfc7155.txt- [ Acct-Link-Count ]
../data/rfc/rfc7155.txt- [ Acct-Session-Time ]
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-
--
../data/rfc/rfc7155.txt- [ Originating-Line-Info ]
../data/rfc/rfc7155.txt- [ Authorization-Lifetime ]
../data/rfc/rfc7155.txt- [ Session-Timeout ]
../data/rfc/rfc7155.txt- [ Idle-Timeout ]
../data/rfc/rfc7155.txt- [ Port-Limit ]
../data/rfc/rfc7155.txt: [ Accounting-Realtime-Required ]
../data/rfc/rfc7155.txt- [ Acct-Interim-Interval ]
../data/rfc/rfc7155.txt- * [ Filter-Id ]
../data/rfc/rfc7155.txt- * [ NAS-Filter-Rule ]
../data/rfc/rfc7155.txt- * [ QoS-Filter-Rule ]
../data/rfc/rfc7155.txt- [ Framed-Appletalk-Link ]
--
../data/rfc/rfc7155.txt-Zorn Standards Track [Page 21]
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-RFC 7155 Diameter NASREQ April 2014
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt:3.10. Accounting-Answer (ACA) Command
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt: The ACA message [RFC6733] is used to acknowledge an Accounting-
../data/rfc/rfc7155.txt: Request command. The Accounting-Answer command contains the same
../data/rfc/rfc7155.txt- Session-Id as the Request.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- Only the target Diameter server or home Diameter server SHOULD
../data/rfc/rfc7155.txt: respond with the Accounting-Answer command.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- The Acct-Application-Id AVP MUST be present.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- The AVPs listed in the Diameter Base protocol specification [RFC6733]
../data/rfc/rfc7155.txt- MUST be assumed to be present, as appropriate. NAS service-specific
../data/rfc/rfc7155.txt: accounting AVPs SHOULD be present as described in Section 4.6 and the
../data/rfc/rfc7155.txt- rest of this specification.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- Message Format
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- <AC-Answer> ::= < Diameter Header: 271, PXY >
../data/rfc/rfc7155.txt- < Session-Id >
../data/rfc/rfc7155.txt- { Result-Code }
../data/rfc/rfc7155.txt- { Origin-Host }
../data/rfc/rfc7155.txt- { Origin-Realm }
../data/rfc/rfc7155.txt: { Accounting-Record-Type }
../data/rfc/rfc7155.txt: { Accounting-Record-Number }
../data/rfc/rfc7155.txt- { Acct-Application-Id }
../data/rfc/rfc7155.txt- [ User-Name ]
../data/rfc/rfc7155.txt: [ Accounting-Sub-Session-Id ]
../data/rfc/rfc7155.txt- [ Acct-Session-Id ]
../data/rfc/rfc7155.txt- [ Acct-Multi-Session-Id ]
../data/rfc/rfc7155.txt- [ Event-Timestamp ]
../data/rfc/rfc7155.txt- [ Error-Message ]
../data/rfc/rfc7155.txt- [ Error-Reporting-Host ]
--
../data/rfc/rfc7155.txt- [ NAS-Port ]
../data/rfc/rfc7155.txt- [ NAS-Port-Id ]
../data/rfc/rfc7155.txt- [ NAS-Port-Type ]
../data/rfc/rfc7155.txt- [ Service-Type ]
../data/rfc/rfc7155.txt- [ Termination-Cause ]
../data/rfc/rfc7155.txt: [ Accounting-Realtime-Required ]
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-
--
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-4.2.7. Connect-Info AVP
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- The Connect-Info AVP (AVP Code 77) is of type UTF8String and is sent
../data/rfc/rfc7155.txt- in the AA-Request message or an ACR message with the value of the
../data/rfc/rfc7155.txt: Accounting-Record-Type AVP set to STOP. When sent in the AA-Request,
../data/rfc/rfc7155.txt- it indicates the nature of the user's connection. The connection
../data/rfc/rfc7155.txt- speed SHOULD be included at the beginning of the first Connect-Info
../data/rfc/rfc7155.txt- AVP in the message. If the transmit and receive connection speeds
../data/rfc/rfc7155.txt- differ, both may be included in the first AVP with the transmit speed
../data/rfc/rfc7155.txt- listed first (the speed at which the NAS modem transmits), then a
../data/rfc/rfc7155.txt- slash (/), then the receive speed, and then other optional
../data/rfc/rfc7155.txt- information.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- For example: "28800 V42BIS/LAPM" or "52000/31200 V90"
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt: If sent in an ACR message with the value of the Accounting-Record-
../data/rfc/rfc7155.txt- Type AVP set to STOP, this attribute may summarize statistics
../data/rfc/rfc7155.txt- relating to session quality. For example, in IEEE 802.11, the
../data/rfc/rfc7155.txt- Connect-Info AVP may contain information on the number of link layer
../data/rfc/rfc7155.txt- retransmissions. The exact format of this attribute is
../data/rfc/rfc7155.txt- implementation specific.
--
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-4.3. NAS Authentication AVPs
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- This section defines the AVPs necessary to carry the authentication
../data/rfc/rfc7155.txt- information in the Diameter protocol. The functionality defined here
../data/rfc/rfc7155.txt: provides a RADIUS-like Authentication, Authorization, and Accounting
../data/rfc/rfc7155.txt- service [RFC2865] over a more reliable and secure transport, as
../data/rfc/rfc7155.txt- defined in the Diameter Base protocol [RFC6733].
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- The following table gives the possible flag values for the session
../data/rfc/rfc7155.txt- level AVPs.
--
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- Some NASes support compulsory tunnel services in which the incoming
../data/rfc/rfc7155.txt- connection data is conveyed by an encapsulation method to a gateway
../data/rfc/rfc7155.txt- elsewhere in the network. This is typically transparent to the
../data/rfc/rfc7155.txt- service user, and the tunnel characteristics may be described by the
../data/rfc/rfc7155.txt: remote Authentication, Authorization, and Accounting server, based on
../data/rfc/rfc7155.txt- the user's authorization information. Several tunnel characteristics
../data/rfc/rfc7155.txt- may be returned, and the NAS implementation may choose one. See
../data/rfc/rfc7155.txt- [RFC2868] and [RFC2867] for further information.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- The following table gives the possible flag values for the session-
--
../data/rfc/rfc7155.txt- the hint in the corresponding response. This AVP SHOULD be included
../data/rfc/rfc7155.txt- in the corresponding ACR messages, in which case it indicates the
../data/rfc/rfc7155.txt- address from which the tunnel was initiated. This AVP, along with
../data/rfc/rfc7155.txt- the Tunnel-Server-Endpoint (Section 4.5.5) and Session-Id AVPs
../data/rfc/rfc7155.txt- ([RFC6733], Section 8.8), can be used to provide a globally unique
../data/rfc/rfc7155.txt: means to identify a tunnel for accounting and auditing purposes.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- If the value of the Tunnel-Medium-Type AVP (Section 4.5.3) is IPv4
../data/rfc/rfc7155.txt- (1), then this string is either the fully qualified domain name
../data/rfc/rfc7155.txt- (FQDN) of the tunnel client machine or a "dotted-decimal" IP address.
../data/rfc/rfc7155.txt- Implementations MUST support the dotted-decimal format and SHOULD
--
../data/rfc/rfc7155.txt- This AVP SHOULD be included in the corresponding ACR messages, in
../data/rfc/rfc7155.txt- which case it indicates the address from which the tunnel was
../data/rfc/rfc7155.txt- initiated. This AVP, along with the Tunnel-Client-Endpoint
../data/rfc/rfc7155.txt- (Section 4.5.4) and Session-Id AVP ([RFC6733], Section 8.8), can be
../data/rfc/rfc7155.txt- used to provide a globally unique means to identify a tunnel for
../data/rfc/rfc7155.txt: accounting and auditing purposes.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- If Tunnel-Medium-Type is IPv4 (1), then this string is either the
../data/rfc/rfc7155.txt- fully qualified domain name (FQDN) of the tunnel server machine, or a
../data/rfc/rfc7155.txt- "dotted-decimal" IP address. Implementations MUST support the
../data/rfc/rfc7155.txt- dotted-decimal format and SHOULD support the FQDN format for IP
--
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- This attribute MAY be included in authorization responses. The
../data/rfc/rfc7155.txt- tunnel initiator receiving this attribute MAY choose to ignore it and
../data/rfc/rfc7155.txt- to assign the session to an arbitrary multiplexed or non-multiplexed
../data/rfc/rfc7155.txt- tunnel between the desired endpoints. This AVP SHOULD also be
../data/rfc/rfc7155.txt: included in the Accounting-Request messages pertaining to the
../data/rfc/rfc7155.txt- tunneled session.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- If a tunnel initiator supports the Tunnel-Assignment-Id AVP, then it
../data/rfc/rfc7155.txt- should assign a session to a tunnel in the following manner:
../data/rfc/rfc7155.txt-
--
../data/rfc/rfc7155.txt- honor the hint in the corresponding response. This AVP MUST be
../data/rfc/rfc7155.txt- present in the authorization response if an authentication name other
../data/rfc/rfc7155.txt- than the default is desired. This AVP SHOULD be included in the ACR
../data/rfc/rfc7155.txt- messages pertaining to the tunneled session.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt:4.6. NAS Accounting AVPs
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt: Applications implementing this specification use Diameter Accounting
../data/rfc/rfc7155.txt- (as defined in [RFC6733]) and the AVPs in the following section.
../data/rfc/rfc7155.txt- Service-specific AVP usage is defined in the tables in Section 5.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt: If accounting is active, Accounting Request (ACR) messages SHOULD be
../data/rfc/rfc7155.txt- sent after the completion of any Authentication or Authorization
../data/rfc/rfc7155.txt- transaction and at the end of a session. The value of the
../data/rfc/rfc7155.txt: Accounting-Record-Type AVP [RFC6733] indicates the type of event.
../data/rfc/rfc7155.txt- All other AVPs identify the session and provide additional
../data/rfc/rfc7155.txt- information relevant to the event.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- The successful completion of the first Authentication or
../data/rfc/rfc7155.txt- Authorization transaction SHOULD cause a START_RECORD to be sent. If
--
../data/rfc/rfc7155.txt- | Rules |
../data/rfc/rfc7155.txt- |----+-----|
../data/rfc/rfc7155.txt- Section |MUST| MUST|
../data/rfc/rfc7155.txt- Attribute Name Defined | | NOT|
../data/rfc/rfc7155.txt- -----------------------------------------|----+-----|
../data/rfc/rfc7155.txt: Accounting-Input-Octets 4.6.1 | M | V |
../data/rfc/rfc7155.txt: Accounting-Output-Octets 4.6.2 | M | V |
../data/rfc/rfc7155.txt: Accounting-Input-Packets 4.6.3 | M | V |
../data/rfc/rfc7155.txt: Accounting-Output-Packets 4.6.4 | M | V |
../data/rfc/rfc7155.txt- Acct-Session-Time 4.6.5 | M | V |
../data/rfc/rfc7155.txt- Acct-Authentic 4.6.6 | M | V |
../data/rfc/rfc7155.txt: Accounting-Auth-Method 4.6.7 | M | V |
../data/rfc/rfc7155.txt- Acct-Delay-Time 4.6.8 | M | V |
../data/rfc/rfc7155.txt- Acct-Link-Count 4.6.9 | M | V |
../data/rfc/rfc7155.txt- Acct-Tunnel-Connection 4.6.10 | M | V |
../data/rfc/rfc7155.txt- Acct-Tunnel-Packets-Lost 4.6.11 | M | V |
../data/rfc/rfc7155.txt- -----------------------------------------|----+-----|
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt:4.6.1. Accounting-Input-Octets AVP
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt: The Accounting-Input-Octets AVP (AVP Code 363) is of type Unsigned64
../data/rfc/rfc7155.txt- and contains the number of octets received from the user.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- For NAS usage, this AVP indicates how many octets have been received
../data/rfc/rfc7155.txt- from the port in the course of this session. It can only be present
../data/rfc/rfc7155.txt: in ACR messages with an Accounting-Record-Type [RFC6733] of
../data/rfc/rfc7155.txt- INTERIM_RECORD or STOP_RECORD.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt:4.6.2. Accounting-Output-Octets AVP
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt: The Accounting-Output-Octets AVP (AVP Code 364) is of type Unsigned64
../data/rfc/rfc7155.txt- and contains the number of octets sent to the user.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- For NAS usage, this AVP indicates how many octets have been sent to
../data/rfc/rfc7155.txt- the port in the course of this session. It can only be present in
../data/rfc/rfc7155.txt: ACR messages with an Accounting-Record-Type of INTERIM_RECORD or
../data/rfc/rfc7155.txt- STOP_RECORD.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt:4.6.3. Accounting-Input-Packets AVP
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt: The Accounting-Input-Packets (AVP Code 365) is of type Unsigned64 and
../data/rfc/rfc7155.txt- contains the number of packets received from the user.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-
--
../data/rfc/rfc7155.txt-RFC 7155 Diameter NASREQ April 2014
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- For NAS usage, this AVP indicates how many packets have been received
../data/rfc/rfc7155.txt- from the port over the course of a session being provided to a Framed
../data/rfc/rfc7155.txt: User. It can only be present in ACR messages with an Accounting-
../data/rfc/rfc7155.txt- Record-Type of INTERIM_RECORD or STOP_RECORD.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt:4.6.4. Accounting-Output-Packets AVP
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt: The Accounting-Output-Packets (AVP Code 366) is of type Unsigned64
../data/rfc/rfc7155.txt- and contains the number of IP packets sent to the user.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- For NAS usage, this AVP indicates how many packets have been sent to
../data/rfc/rfc7155.txt- the port over the course of a session being provided to a Framed
../data/rfc/rfc7155.txt: User. It can only be present in ACR messages with an Accounting-
../data/rfc/rfc7155.txt- Record-Type of INTERIM_RECORD or STOP_RECORD.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-4.6.5. Acct-Session-Time AVP
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- The Acct-Session-Time AVP (AVP Code 46) is of type Unsigned32 and
../data/rfc/rfc7155.txt- indicates the length of the current session in seconds. It can only
../data/rfc/rfc7155.txt: be present in ACR messages with an Accounting-Record-Type of
../data/rfc/rfc7155.txt- INTERIM_RECORD or STOP_RECORD.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-4.6.6. Acct-Authentic AVP
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- The Acct-Authentic AVP (AVP Code 45) is of type Enumerated and
../data/rfc/rfc7155.txt- specifies how the user was authenticated. The supported values are
../data/rfc/rfc7155.txt- listed in [RADIUSAttrVals].
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt:4.6.7. Accounting-Auth-Method AVP
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt: The Accounting-Auth-Method AVP (AVP Code 406) is of type Enumerated.
../data/rfc/rfc7155.txt: A NAS MAY include this AVP in an Accounting-Request message to
../data/rfc/rfc7155.txt- indicate the method used to authenticate the user. (Note that this
../data/rfc/rfc7155.txt- AVP is semantically equivalent, and the supported values are
../data/rfc/rfc7155.txt- identical, to the Microsoft MS-Acct-Auth-Type vendor-specific RADIUS
../data/rfc/rfc7155.txt- attribute [RFC2548]).
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-4.6.8. Acct-Delay-Time AVP
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- The Acct-Delay-Time AVP (AVP Code 41) is of type Unsigned32 and
../data/rfc/rfc7155.txt- indicates the number of seconds the Diameter client has been trying
../data/rfc/rfc7155.txt: to send the Accounting-Request (ACR). The accounting server may
../data/rfc/rfc7155.txt- subtract this value from the time when the ACR arrives at the server
../data/rfc/rfc7155.txt- to calculate the approximate time of the event that caused the ACR to
../data/rfc/rfc7155.txt- be generated.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-
--
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-4.6.9. Acct-Link-Count AVP
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- The Acct-Link-Count AVP (AVP Code 51) is of type Unsigned32 and
../data/rfc/rfc7155.txt- indicates the total number of links that have been active (current or
../data/rfc/rfc7155.txt: closed) in a given multilink session at the time the accounting
../data/rfc/rfc7155.txt: record is generated. This AVP MAY be included in Accounting-Request
../data/rfc/rfc7155.txt- AVPs for any session that may be part of a multilink service.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- The Acct-Link-Count AVP may be used to make it easier for an
../data/rfc/rfc7155.txt: accounting server to know when it has all the records for a given
../data/rfc/rfc7155.txt: multilink service. When the number of Accounting-Request AVPs
../data/rfc/rfc7155.txt: received with Accounting-Record-Type = STOP_RECORD and with the same
../data/rfc/rfc7155.txt- Acct-Multi-Session-Id and unique Session-Id AVPs equals the largest
../data/rfc/rfc7155.txt: value of Acct-Link-Count seen in those Accounting-Request AVPs, all
../data/rfc/rfc7155.txt: STOP_RECORD Accounting-Request AVPs for that multilink service have
../data/rfc/rfc7155.txt- been received.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt: The following example, showing eight Accounting-Request AVPs,
../data/rfc/rfc7155.txt- illustrates how the Acct-Link-Count AVP is used. In the table below,
../data/rfc/rfc7155.txt- only the relevant AVPs are shown, although additional AVPs containing
../data/rfc/rfc7155.txt: accounting information will be present in the Accounting-Requests
../data/rfc/rfc7155.txt- AVPs.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-
--
../data/rfc/rfc7155.txt-Zorn Standards Track [Page 54]
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-RFC 7155 Diameter NASREQ April 2014
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt: Acct-Multi- Accounting- Acct-
../data/rfc/rfc7155.txt- Session-Id Session-Id Record-Type Link-Count
../data/rfc/rfc7155.txt- --------------------------------------------------------
../data/rfc/rfc7155.txt- "...10" "...10" START_RECORD 1
../data/rfc/rfc7155.txt- "...10" "...11" START_RECORD 2
../data/rfc/rfc7155.txt- "...10" "...11" STOP_RECORD 2
--
../data/rfc/rfc7155.txt- Tunneling | 0+ | 0+ |
../data/rfc/rfc7155.txt- User-Name | 0-1 | 0-1 |
../data/rfc/rfc7155.txt- User-Password | 0-1 | 0 |
../data/rfc/rfc7155.txt- ------------------------------|-----+-----+
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt:5.2. Accounting AVP Tables
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- The tables in this section are used to show which AVPs defined in
../data/rfc/rfc7155.txt- this document are to be present and used in NAS application
../data/rfc/rfc7155.txt: Accounting messages. These AVPs are defined in this document, as
../data/rfc/rfc7155.txt- well as in [RFC6733] and [RFC2866].
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-
--
../data/rfc/rfc7155.txt-Zorn Standards Track [Page 58]
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-RFC 7155 Diameter NASREQ April 2014
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt:5.2.1. Framed Access Accounting AVP Table
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- The table in this section is used when the Service-Type AVP
../data/rfc/rfc7155.txt- (Section 4.4.1) specifies Framed Access.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- +-----------+
../data/rfc/rfc7155.txt- | Command |
../data/rfc/rfc7155.txt- |-----+-----+
../data/rfc/rfc7155.txt- Attribute Name | ACR | ACA |
../data/rfc/rfc7155.txt- ---------------------------------------|-----+-----+
../data/rfc/rfc7155.txt: Accounting-Auth-Method | 0-1 | 0 |
../data/rfc/rfc7155.txt: Accounting-Input-Octets | 1 | 0 |
../data/rfc/rfc7155.txt: Accounting-Input-Packets | 1 | 0 |
../data/rfc/rfc7155.txt: Accounting-Output-Octets | 1 | 0 |
../data/rfc/rfc7155.txt: Accounting-Output-Packets | 1 | 0 |
../data/rfc/rfc7155.txt: Accounting-Record-Number | 0-1 | 0-1 |
../data/rfc/rfc7155.txt: Accounting-Record-Type | 1 | 1 |
../data/rfc/rfc7155.txt: Accounting-Realtime-Required | 0-1 | 0-1 |
../data/rfc/rfc7155.txt: Accounting-Sub-Session-Id | 0-1 | 0-1 |
../data/rfc/rfc7155.txt- Acct-Application-Id | 0-1 | 0-1 |
../data/rfc/rfc7155.txt- Acct-Session-Id | 1 | 0-1 |
../data/rfc/rfc7155.txt- Acct-Multi-Session-Id | 0-1 | 0-1 |
../data/rfc/rfc7155.txt- Acct-Authentic | 1 | 0 |
../data/rfc/rfc7155.txt- Acct-Delay-Time | 0-1 | 0 |
--
../data/rfc/rfc7155.txt-Zorn Standards Track [Page 60]
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-RFC 7155 Diameter NASREQ April 2014
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt:5.2.2. Non-Framed Access Accounting AVP Table
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- The table in this section is used when the Service-Type AVP
../data/rfc/rfc7155.txt- (Section 4.4.1) specifies Non-Framed Access.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- +-----------+
../data/rfc/rfc7155.txt- | Command |
../data/rfc/rfc7155.txt- |-----+-----+
../data/rfc/rfc7155.txt- Attribute Name | ACR | ACA |
../data/rfc/rfc7155.txt- ---------------------------------------|-----+-----+
../data/rfc/rfc7155.txt: Accounting-Auth-Method | 0-1 | 0 |
../data/rfc/rfc7155.txt: Accounting-Input-Octets | 1 | 0 |
../data/rfc/rfc7155.txt: Accounting-Output-Octets | 1 | 0 |
../data/rfc/rfc7155.txt: Accounting-Record-Type | 1 | 1 |
../data/rfc/rfc7155.txt: Accounting-Record-Number | 0-1 | 0-1 |
../data/rfc/rfc7155.txt: Accounting-Realtime-Required | 0-1 | 0-1 |
../data/rfc/rfc7155.txt: Accounting-Sub-Session-Id | 0-1 | 0-1 |
../data/rfc/rfc7155.txt- Acct-Application-Id | 0-1 | 0-1 |
../data/rfc/rfc7155.txt- Acct-Session-Id | 1 | 0-1 |
../data/rfc/rfc7155.txt- Acct-Multi-Session-Id | 0-1 | 0-1 |
../data/rfc/rfc7155.txt- Acct-Authentic | 1 | 0 |
../data/rfc/rfc7155.txt- Acct-Delay-Time | 0-1 | 0 |
--
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- [RFC3516] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516,
../data/rfc/rfc7155.txt- April 2003.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
../data/rfc/rfc7155.txt: Accounting (AAA) Transport Profile", RFC 3539, June 2003.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
../data/rfc/rfc7155.txt- Specifications: ABNF", STD 68, RFC 5234, January 2008.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M.,
--
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little,
../data/rfc/rfc7155.txt- W., and G. Zorn, "Point-to-Point Tunneling Protocol", RFC
../data/rfc/rfc7155.txt- 2637, July 1999.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt: [RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting
../data/rfc/rfc7155.txt- Modifications for Tunnel Protocol Support", RFC 2867, June
../data/rfc/rfc7155.txt- 2000.
../data/rfc/rfc7155.txt-
../data/rfc/rfc7155.txt- [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
../data/rfc/rfc7155.txt- M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol
--
../data/rfc/rfc3717.txt-
../data/rfc/rfc3717.txt-RFC 3717 IP over Optical Networks: A Framework March 2004
../data/rfc/rfc3717.txt-
../data/rfc/rfc3717.txt-
../data/rfc/rfc3717.txt- o Policies regarding the dynamic provisioning of optical paths
../data/rfc/rfc3717.txt: between routers. These include access control, accounting, and
../data/rfc/rfc3717.txt- security issues.
../data/rfc/rfc3717.txt-
../data/rfc/rfc3717.txt- The following interconnection models are then possible:
../data/rfc/rfc3717.txt-
../data/rfc/rfc3717.txt-5.1. Interconnection Models
--
../data/rfc/rfc3323.txt- target for unsolicited advertising, legal censure or other
../data/rfc/rfc3323.txt- undesirable consequences
../data/rfc/rfc3323.txt-
../data/rfc/rfc3323.txt- Users might want to withhold from participants in a session the
../data/rfc/rfc3323.txt- identity by which they are known to network intermediaries for the
../data/rfc/rfc3323.txt: purposes of billing and accounting
../data/rfc/rfc3323.txt-
../data/rfc/rfc3323.txt- When a user agent decides to send a request through a proxy server,
../data/rfc/rfc3323.txt- it may be difficult for the originator to anticipate the final
../data/rfc/rfc3323.txt- destination of that message. For that reason, users are advised not
../data/rfc/rfc3323.txt- to base their estimation of their privacy needs on where they expect
--
../data/rfc/rfc640.txt- information, such as status or help. 11g2
../data/rfc/rfc640.txt-
../data/rfc/rfc640.txt- x2z Connections - Replies referring to the TELNET and
../data/rfc/rfc640.txt- data connections. 11g3
../data/rfc/rfc640.txt-
../data/rfc/rfc640.txt: x3z Authentication and accounting - Replies for the logon
../data/rfc/rfc640.txt: process and accounting procedures. 11g4
../data/rfc/rfc640.txt-
../data/rfc/rfc640.txt- x4z Unspecified as yet 11g5
../data/rfc/rfc640.txt-
../data/rfc/rfc640.txt- x5z File system - These replies indicate the status of
../data/rfc/rfc640.txt- the Server file system vis-a-vis the requested
--
../data/rfc/rfc4670.txt-Request for Comments: 4670 Enterasys Networks
../data/rfc/rfc4670.txt-Obsoletes: 2620 August 2006
../data/rfc/rfc4670.txt-Category: Informational
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt: RADIUS Accounting Client MIB for IPv6
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-Status of This Memo
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- This memo provides information for the Internet community. It does
../data/rfc/rfc4670.txt- not specify an Internet standard of any kind. Distribution of this
--
../data/rfc/rfc4670.txt- Copyright (C) The Internet Society (2006).
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-Abstract
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- This memo defines a set of extensions that instrument RADIUS
../data/rfc/rfc4670.txt: accounting client functions. These extensions represent a portion of
../data/rfc/rfc4670.txt- the Management Information Base (MIB) for use with network management
../data/rfc/rfc4670.txt- protocols in the Internet community. Using these extensions,
../data/rfc/rfc4670.txt: IP-based management stations can manage RADIUS accounting clients.
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- This memo obsoletes RFC 2620 by deprecating the MIB table containing
../data/rfc/rfc4670.txt- IPv4-only address formats and defining a new table to add support for
../data/rfc/rfc4670.txt- version-neutral IP address formats. The remaining MIB objects from
../data/rfc/rfc4670.txt- RFC 2620 are carried forward into this document. This memo also adds
--
../data/rfc/rfc4670.txt-1. Introduction
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- This memo defines a portion of the Management Information Base (MIB)
../data/rfc/rfc4670.txt- for use with network management protocols in the Internet community.
../data/rfc/rfc4670.txt- The objects defined within this memo relate to the Remote
../data/rfc/rfc4670.txt: Authentication Dial-In User Service (RADIUS) Accounting Client as
../data/rfc/rfc4670.txt- defined in RFC 2866 [RFC2866].
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-2. Terminology
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
--
../data/rfc/rfc4670.txt- RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
../data/rfc/rfc4670.txt- [RFC2580].
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-4. Scope of Changes
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt: This document obsoletes RFC 2620 [RFC2620], RADIUS Accounting Client
../data/rfc/rfc4670.txt- MIB, by deprecating the radiusAccServerTable table and adding a new
../data/rfc/rfc4670.txt- table, radiusAccServerExtTable, containing
../data/rfc/rfc4670.txt- radiusAccServerInetAddressType, radiusAccServerInetAddress, and
../data/rfc/rfc4670.txt- radiusAccClientServerInetPortNumber. The purpose of these added MIB
../data/rfc/rfc4670.txt- objects is to support version-neutral IP addressing formats. The
--
../data/rfc/rfc4670.txt- changed to "deprecated". The other approach, of having multiple
../data/rfc/rfc4670.txt- similar tables for different IP versions, is strongly discouraged.'
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-5. Structure of the MIB Module
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt: The RADIUS accounting protocol, described in RFC 2866 [RFC2866],
../data/rfc/rfc4670.txt- distinguishes between the client function and the server function.
../data/rfc/rfc4670.txt: In RADIUS accounting, clients send Accounting-Requests, and servers
../data/rfc/rfc4670.txt: reply with Accounting-Responses. Typically, Network Access Server
../data/rfc/rfc4670.txt- (NAS) devices implement the client function, and thus would be
../data/rfc/rfc4670.txt: expected to implement the RADIUS accounting client MIB, while RADIUS
../data/rfc/rfc4670.txt: accounting servers implement the server function, and thus would be
../data/rfc/rfc4670.txt: expected to implement the RADIUS accounting server MIB.
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt: However, it is possible for a RADIUS accounting entity to perform
../data/rfc/rfc4670.txt- both client and server functions. For example, a RADIUS proxy may
../data/rfc/rfc4670.txt: act as a server to one or more RADIUS accounting clients, while
../data/rfc/rfc4670.txt: simultaneously acting as an accounting client to one or more
../data/rfc/rfc4670.txt: accounting servers. In such situations, it is expected that RADIUS
../data/rfc/rfc4670.txt- entities combining client and server functionality will support both
../data/rfc/rfc4670.txt- the client and server MIBs. The client MIB is defined in this
../data/rfc/rfc4670.txt- document, and the server MIB is defined in [RFC4671].
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- This MIB module contains two scalars as well as a single table, the
../data/rfc/rfc4670.txt: RADIUS Accounting Server Table, which contains one row for each
../data/rfc/rfc4670.txt- RADIUS server with which the client shares a secret. Each entry in
../data/rfc/rfc4670.txt: the RADIUS Accounting Server Table includes fifteen columns
../data/rfc/rfc4670.txt- presenting a view of the activity of the RADIUS client.
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- This MIB imports from [RFC2578], [RFC2580], [RFC3411], and [RFC4001].
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-
--
../data/rfc/rfc4670.txt- accurately be represented in both the new table and the
../data/rfc/rfc4670.txt- deprecated table.
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- Managed entities SHOULD NOT instantiate row entries in the deprecated
../data/rfc/rfc4670.txt- table, containing IPv4-only address objects, when the RADIUS
../data/rfc/rfc4670.txt: accounting server address represented in such a table row is not an
../data/rfc/rfc4670.txt- IPv4 address. Managed entities SHOULD NOT return inaccurate values
../data/rfc/rfc4670.txt- of IP address or SNMP object access errors for IPv4-only address
../data/rfc/rfc4670.txt- objects in otherwise populated tables. When row entries exist in
../data/rfc/rfc4670.txt- both the deprecated IPv4-only table and the new IP-version-neutral
../data/rfc/rfc4670.txt: table that describe the same RADIUS accounting server, the row
../data/rfc/rfc4670.txt- indexes SHOULD be the same for the corresponding rows in each table,
../data/rfc/rfc4670.txt- to facilitate correlation of these related rows by management
../data/rfc/rfc4670.txt- applications.
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-7. Definitions
--
../data/rfc/rfc4670.txt- Phone: +1 425 936 6605
../data/rfc/rfc4670.txt- EMail: bernarda@microsoft.com"
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt- "The MIB module for entities implementing the client
../data/rfc/rfc4670.txt- side of the Remote Authentication Dial-In User Service
../data/rfc/rfc4670.txt: (RADIUS) accounting protocol. Copyright (C) The
../data/rfc/rfc4670.txt- Internet Society (2006). This version of this MIB
../data/rfc/rfc4670.txt- module is part of RFC 4670; see the RFC itself for
../data/rfc/rfc4670.txt- full legal notices."
../data/rfc/rfc4670.txt- REVISION "200608210000Z" -- 21 August 2006
../data/rfc/rfc4670.txt- DESCRIPTION
--
../data/rfc/rfc4670.txt- for version-neutral IP address formats. The remaining
../data/rfc/rfc4670.txt- MIB objects from RFC 2620 are carried forward into this
../data/rfc/rfc4670.txt- version."
../data/rfc/rfc4670.txt- REVISION "199906110000Z" -- 11 Jun 1999
../data/rfc/rfc4670.txt- DESCRIPTION "Initial version as published in RFC 2620."
../data/rfc/rfc4670.txt: ::= { radiusAccounting 2 }
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- radiusMIB OBJECT-IDENTITY
../data/rfc/rfc4670.txt- STATUS current
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt- "The OID assigned to RADIUS MIB work by the IANA."
../data/rfc/rfc4670.txt- ::= { mib-2 67 }
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt: radiusAccounting OBJECT IDENTIFIER ::= {radiusMIB 2}
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- radiusAccClientMIBObjects OBJECT IDENTIFIER
../data/rfc/rfc4670.txt- ::= { radiusAccClientMIB 1 }
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- radiusAccClient OBJECT IDENTIFIER
--
../data/rfc/rfc4670.txt- SYNTAX Counter32
../data/rfc/rfc4670.txt- UNITS "packets"
../data/rfc/rfc4670.txt- MAX-ACCESS read-only
../data/rfc/rfc4670.txt- STATUS current
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt: "The number of RADIUS Accounting-Response packets
../data/rfc/rfc4670.txt- received from unknown addresses."
../data/rfc/rfc4670.txt- ::= { radiusAccClient 1 }
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-
--
../data/rfc/rfc4670.txt- radiusAccClientIdentifier OBJECT-TYPE
../data/rfc/rfc4670.txt- SYNTAX SnmpAdminString
../data/rfc/rfc4670.txt- MAX-ACCESS read-only
../data/rfc/rfc4670.txt- STATUS current
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt: "The NAS-Identifier of the RADIUS accounting client.
../data/rfc/rfc4670.txt- This is not necessarily the same as sysName in MIB
../data/rfc/rfc4670.txt- II."
../data/rfc/rfc4670.txt- REFERENCE "RFC 2865 section 5.32"
../data/rfc/rfc4670.txt- ::= { radiusAccClient 2 }
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- radiusAccServerTable OBJECT-TYPE
../data/rfc/rfc4670.txt- SYNTAX SEQUENCE OF RadiusAccServerEntry
../data/rfc/rfc4670.txt- MAX-ACCESS not-accessible
../data/rfc/rfc4670.txt- STATUS deprecated
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt: "The (conceptual) table listing the RADIUS accounting
../data/rfc/rfc4670.txt- servers with which the client shares a secret."
../data/rfc/rfc4670.txt- ::= { radiusAccClient 3 }
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- radiusAccServerEntry OBJECT-TYPE
../data/rfc/rfc4670.txt- SYNTAX RadiusAccServerEntry
../data/rfc/rfc4670.txt- MAX-ACCESS not-accessible
../data/rfc/rfc4670.txt- STATUS deprecated
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt- "An entry (conceptual row) representing a RADIUS
../data/rfc/rfc4670.txt: accounting server with which the client shares a
../data/rfc/rfc4670.txt- secret."
../data/rfc/rfc4670.txt- INDEX { radiusAccServerIndex }
../data/rfc/rfc4670.txt- ::= { radiusAccServerTable 1 }
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- RadiusAccServerEntry ::= SEQUENCE {
--
../data/rfc/rfc4670.txt- SYNTAX Integer32 (1..2147483647)
../data/rfc/rfc4670.txt- MAX-ACCESS not-accessible
../data/rfc/rfc4670.txt- STATUS deprecated
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt- "A number uniquely identifying each RADIUS
../data/rfc/rfc4670.txt: Accounting server with which this client
../data/rfc/rfc4670.txt- communicates."
../data/rfc/rfc4670.txt- ::= { radiusAccServerEntry 1 }
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- radiusAccServerAddress OBJECT-TYPE
../data/rfc/rfc4670.txt- SYNTAX IpAddress
../data/rfc/rfc4670.txt- MAX-ACCESS read-only
../data/rfc/rfc4670.txt- STATUS deprecated
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt: "The IP address of the RADIUS accounting server
../data/rfc/rfc4670.txt- referred to in this table entry."
../data/rfc/rfc4670.txt- ::= { radiusAccServerEntry 2 }
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- radiusAccClientServerPortNumber OBJECT-TYPE
../data/rfc/rfc4670.txt- SYNTAX Integer32 (0..65535)
--
../data/rfc/rfc4670.txt- SYNTAX TimeTicks
../data/rfc/rfc4670.txt- MAX-ACCESS read-only
../data/rfc/rfc4670.txt- STATUS deprecated
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt- "The time interval between the most recent
../data/rfc/rfc4670.txt: Accounting-Response and the Accounting-Request that
../data/rfc/rfc4670.txt: matched it from this RADIUS accounting server."
../data/rfc/rfc4670.txt- REFERENCE "RFC 2866 section 2"
../data/rfc/rfc4670.txt- ::= { radiusAccServerEntry 4 }
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- -- Request/Response statistics
../data/rfc/rfc4670.txt- --
--
../data/rfc/rfc4670.txt- SYNTAX Counter32
../data/rfc/rfc4670.txt- UNITS "packets"
../data/rfc/rfc4670.txt- MAX-ACCESS read-only
../data/rfc/rfc4670.txt- STATUS deprecated
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt: "The number of RADIUS Accounting-Request packets
../data/rfc/rfc4670.txt- sent. This does not include retransmissions."
../data/rfc/rfc4670.txt- REFERENCE "RFC 2866 section 4.1"
../data/rfc/rfc4670.txt- ::= { radiusAccServerEntry 5 }
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- radiusAccClientRetransmissions OBJECT-TYPE
../data/rfc/rfc4670.txt- SYNTAX Counter32
../data/rfc/rfc4670.txt- UNITS "packets"
../data/rfc/rfc4670.txt- MAX-ACCESS read-only
../data/rfc/rfc4670.txt- STATUS deprecated
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt: "The number of RADIUS Accounting-Request packets
../data/rfc/rfc4670.txt: retransmitted to this RADIUS accounting server.
../data/rfc/rfc4670.txt- Retransmissions include retries where the
../data/rfc/rfc4670.txt- Identifier and Acct-Delay have been updated, as
../data/rfc/rfc4670.txt- well as those in which they remain the same."
../data/rfc/rfc4670.txt- REFERENCE "RFC 2866 section 2"
../data/rfc/rfc4670.txt- ::= { radiusAccServerEntry 6 }
--
../data/rfc/rfc4670.txt- UNITS "packets"
../data/rfc/rfc4670.txt- MAX-ACCESS read-only
../data/rfc/rfc4670.txt- STATUS deprecated
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt- "The number of RADIUS packets received on the
../data/rfc/rfc4670.txt: accounting port from this server."
../data/rfc/rfc4670.txt- REFERENCE "RFC 2866 section 4.2"
../data/rfc/rfc4670.txt- ::= { radiusAccServerEntry 7 }
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- radiusAccClientMalformedResponses OBJECT-TYPE
../data/rfc/rfc4670.txt- SYNTAX Counter32
../data/rfc/rfc4670.txt- UNITS "packets"
../data/rfc/rfc4670.txt- MAX-ACCESS read-only
../data/rfc/rfc4670.txt- STATUS deprecated
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt: "The number of malformed RADIUS Accounting-Response
../data/rfc/rfc4670.txt- packets received from this server. Malformed packets
../data/rfc/rfc4670.txt- include packets with an invalid length. Bad
../data/rfc/rfc4670.txt- authenticators and unknown types are not included as
../data/rfc/rfc4670.txt: malformed accounting responses."
../data/rfc/rfc4670.txt- REFERENCE "RFC 2866 section 3"
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-Nelson Informational [Page 9]
--
../data/rfc/rfc4670.txt- SYNTAX Counter32
../data/rfc/rfc4670.txt- UNITS "packets"
../data/rfc/rfc4670.txt- MAX-ACCESS read-only
../data/rfc/rfc4670.txt- STATUS deprecated
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt: "The number of RADIUS Accounting-Response
../data/rfc/rfc4670.txt- packets that contained invalid authenticators
../data/rfc/rfc4670.txt- received from this server."
../data/rfc/rfc4670.txt- REFERENCE "RFC 2866 section 3"
../data/rfc/rfc4670.txt- ::= { radiusAccServerEntry 9 }
../data/rfc/rfc4670.txt-
--
../data/rfc/rfc4670.txt- SYNTAX Gauge32
../data/rfc/rfc4670.txt- UNITS "packets"
../data/rfc/rfc4670.txt- MAX-ACCESS read-only
../data/rfc/rfc4670.txt- STATUS deprecated
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt: "The number of RADIUS Accounting-Request packets
../data/rfc/rfc4670.txt- sent to this server that have not yet timed out or
../data/rfc/rfc4670.txt- received a response. This variable is incremented
../data/rfc/rfc4670.txt: when an Accounting-Request is sent and decremented
../data/rfc/rfc4670.txt: due to receipt of an Accounting-Response, a timeout,
../data/rfc/rfc4670.txt- or a retransmission."
../data/rfc/rfc4670.txt- REFERENCE "RFC 2866 section 2"
../data/rfc/rfc4670.txt- ::= { radiusAccServerEntry 10 }
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- radiusAccClientTimeouts OBJECT-TYPE
../data/rfc/rfc4670.txt- SYNTAX Counter32
../data/rfc/rfc4670.txt- UNITS "timeouts"
../data/rfc/rfc4670.txt- MAX-ACCESS read-only
../data/rfc/rfc4670.txt- STATUS deprecated
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt: "The number of accounting timeouts to this server.
../data/rfc/rfc4670.txt- After a timeout, the client may retry to the same
../data/rfc/rfc4670.txt- server, send to a different server, or give up.
../data/rfc/rfc4670.txt- A retry to the same server is counted as a
../data/rfc/rfc4670.txt- retransmit as well as a timeout. A send to a different
../data/rfc/rfc4670.txt: server is counted as an Accounting-Request as well as
../data/rfc/rfc4670.txt- a timeout."
../data/rfc/rfc4670.txt- REFERENCE "RFC 2866 section 2"
../data/rfc/rfc4670.txt- ::= { radiusAccServerEntry 11 }
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- radiusAccClientUnknownTypes OBJECT-TYPE
--
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- MAX-ACCESS read-only
../data/rfc/rfc4670.txt- STATUS deprecated
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt- "The number of RADIUS packets of unknown type that
../data/rfc/rfc4670.txt: were received from this server on the accounting port."
../data/rfc/rfc4670.txt- REFERENCE "RFC 2866 section 4"
../data/rfc/rfc4670.txt- ::= { radiusAccServerEntry 12 }
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- radiusAccClientPacketsDropped OBJECT-TYPE
../data/rfc/rfc4670.txt- SYNTAX Counter32
../data/rfc/rfc4670.txt- UNITS "packets"
../data/rfc/rfc4670.txt- MAX-ACCESS read-only
../data/rfc/rfc4670.txt- STATUS deprecated
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt- "The number of RADIUS packets that were received from
../data/rfc/rfc4670.txt: this server on the accounting port and dropped for some
../data/rfc/rfc4670.txt- other reason."
../data/rfc/rfc4670.txt- ::= { radiusAccServerEntry 13 }
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- -- New MIB objects added in this revision
--
../data/rfc/rfc4670.txt- radiusAccServerExtTable OBJECT-TYPE
../data/rfc/rfc4670.txt- SYNTAX SEQUENCE OF RadiusAccServerExtEntry
../data/rfc/rfc4670.txt- MAX-ACCESS not-accessible
../data/rfc/rfc4670.txt- STATUS current
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt: "The (conceptual) table listing the RADIUS accounting
../data/rfc/rfc4670.txt- servers with which the client shares a secret."
../data/rfc/rfc4670.txt- ::= { radiusAccClient 4 }
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- radiusAccServerExtEntry OBJECT-TYPE
../data/rfc/rfc4670.txt- SYNTAX RadiusAccServerExtEntry
../data/rfc/rfc4670.txt- MAX-ACCESS not-accessible
../data/rfc/rfc4670.txt- STATUS current
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt- "An entry (conceptual row) representing a RADIUS
../data/rfc/rfc4670.txt: accounting server with which the client shares a
../data/rfc/rfc4670.txt- secret."
../data/rfc/rfc4670.txt- INDEX { radiusAccServerExtIndex }
../data/rfc/rfc4670.txt- ::= { radiusAccServerExtTable 1 }
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- RadiusAccServerExtEntry ::= SEQUENCE {
--
../data/rfc/rfc4670.txt- SYNTAX Integer32 (1..2147483647)
../data/rfc/rfc4670.txt- MAX-ACCESS not-accessible
../data/rfc/rfc4670.txt- STATUS current
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt- "A number uniquely identifying each RADIUS
../data/rfc/rfc4670.txt: Accounting server with which this client
../data/rfc/rfc4670.txt- communicates."
../data/rfc/rfc4670.txt- ::= { radiusAccServerExtEntry 1 }
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- radiusAccServerInetAddressType OBJECT-TYPE
--
../data/rfc/rfc4670.txt- radiusAccServerInetAddress OBJECT-TYPE
../data/rfc/rfc4670.txt- SYNTAX InetAddress
../data/rfc/rfc4670.txt- MAX-ACCESS read-only
../data/rfc/rfc4670.txt- STATUS current
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt: "The IP address of the RADIUS accounting
../data/rfc/rfc4670.txt- server referred to in this table entry, using
../data/rfc/rfc4670.txt- the version-neutral IP address format."
../data/rfc/rfc4670.txt- ::= { radiusAccServerExtEntry 3 }
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- radiusAccClientServerInetPortNumber OBJECT-TYPE
--
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-RFC 4670 RADIUS Acct Client MIB (IPv6) August 2006
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- "The UDP port the client is using to send requests
../data/rfc/rfc4670.txt: to this accounting server. The value zero (0) is
../data/rfc/rfc4670.txt- invalid."
../data/rfc/rfc4670.txt- REFERENCE "RFC 2866 section 3"
../data/rfc/rfc4670.txt- ::= { radiusAccServerExtEntry 4 }
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-
--
../data/rfc/rfc4670.txt- SYNTAX TimeTicks
../data/rfc/rfc4670.txt- MAX-ACCESS read-only
../data/rfc/rfc4670.txt- STATUS current
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt- "The time interval between the most recent
../data/rfc/rfc4670.txt: Accounting-Response and the Accounting-Request that
../data/rfc/rfc4670.txt: matched it from this RADIUS accounting server."
../data/rfc/rfc4670.txt- REFERENCE "RFC 2866 section 2"
../data/rfc/rfc4670.txt- ::= { radiusAccServerExtEntry 5 }
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- -- Request/Response statistics
../data/rfc/rfc4670.txt- --
--
../data/rfc/rfc4670.txt- SYNTAX Counter32
../data/rfc/rfc4670.txt- UNITS "packets"
../data/rfc/rfc4670.txt- MAX-ACCESS read-only
../data/rfc/rfc4670.txt- STATUS current
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt: "The number of RADIUS Accounting-Request packets
../data/rfc/rfc4670.txt- sent. This does not include retransmissions.
../data/rfc/rfc4670.txt- This counter may experience a discontinuity when the
../data/rfc/rfc4670.txt: RADIUS Accounting Client module within the managed
../data/rfc/rfc4670.txt- entity is reinitialized, as indicated by the current
../data/rfc/rfc4670.txt- value of radiusAccClientCounterDiscontinuity."
../data/rfc/rfc4670.txt- REFERENCE "RFC 2866 section 4.1"
../data/rfc/rfc4670.txt- ::= { radiusAccServerExtEntry 6 }
../data/rfc/rfc4670.txt-
--
../data/rfc/rfc4670.txt- SYNTAX Counter32
../data/rfc/rfc4670.txt- UNITS "packets"
../data/rfc/rfc4670.txt- MAX-ACCESS read-only
../data/rfc/rfc4670.txt- STATUS current
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt: "The number of RADIUS Accounting-Request packets
../data/rfc/rfc4670.txt: retransmitted to this RADIUS accounting server.
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-Nelson Informational [Page 13]
../data/rfc/rfc4670.txt-
--
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- Retransmissions include retries where the
../data/rfc/rfc4670.txt- Identifier and Acct-Delay have been updated, as
../data/rfc/rfc4670.txt- well as those in which they remain the same.
../data/rfc/rfc4670.txt- This counter may experience a discontinuity when the
../data/rfc/rfc4670.txt: RADIUS Accounting Client module within the managed
../data/rfc/rfc4670.txt- entity is reinitialized, as indicated by the current
../data/rfc/rfc4670.txt- value of radiusAccClientCounterDiscontinuity."
../data/rfc/rfc4670.txt- REFERENCE "RFC 2866 section 2"
../data/rfc/rfc4670.txt- ::= { radiusAccServerExtEntry 7 }
../data/rfc/rfc4670.txt-
--
../data/rfc/rfc4670.txt- UNITS "packets"
../data/rfc/rfc4670.txt- MAX-ACCESS read-only
../data/rfc/rfc4670.txt- STATUS current
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt- "The number of RADIUS packets received on the
../data/rfc/rfc4670.txt: accounting port from this server. This counter
../data/rfc/rfc4670.txt- may experience a discontinuity when the RADIUS
../data/rfc/rfc4670.txt: Accounting Client module within the managed entity is
../data/rfc/rfc4670.txt- reinitialized, as indicated by the current value of
../data/rfc/rfc4670.txt- radiusAccClientCounterDiscontinuity."
../data/rfc/rfc4670.txt- REFERENCE "RFC 2866 section 4.2"
../data/rfc/rfc4670.txt- ::= { radiusAccServerExtEntry 8 }
../data/rfc/rfc4670.txt-
--
../data/rfc/rfc4670.txt- SYNTAX Counter32
../data/rfc/rfc4670.txt- UNITS "packets"
../data/rfc/rfc4670.txt- MAX-ACCESS read-only
../data/rfc/rfc4670.txt- STATUS current
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt: "The number of malformed RADIUS Accounting-Response
../data/rfc/rfc4670.txt- packets received from this server. Malformed packets
../data/rfc/rfc4670.txt- include packets with an invalid length. Bad
../data/rfc/rfc4670.txt- authenticators and unknown types are not included as
../data/rfc/rfc4670.txt: malformed accounting responses. This counter may
../data/rfc/rfc4670.txt: experience a discontinuity when the RADIUS Accounting
../data/rfc/rfc4670.txt- Client module within the managed entity is
../data/rfc/rfc4670.txt- reinitialized, as indicated by the current
../data/rfc/rfc4670.txt- value of radiusAccClientCounterDiscontinuity."
../data/rfc/rfc4670.txt- REFERENCE "RFC 2866 section 3"
../data/rfc/rfc4670.txt- ::= { radiusAccServerExtEntry 9 }
--
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-RFC 4670 RADIUS Acct Client MIB (IPv6) August 2006
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt: "The number of RADIUS Accounting-Response
../data/rfc/rfc4670.txt- packets that contained invalid authenticators
../data/rfc/rfc4670.txt- received from this server. This counter may
../data/rfc/rfc4670.txt- experience a discontinuity when the RADIUS
../data/rfc/rfc4670.txt: Accounting Client module within the managed
../data/rfc/rfc4670.txt- entity is reinitialized, as indicated by the
../data/rfc/rfc4670.txt- current value of
../data/rfc/rfc4670.txt- radiusAccClientCounterDiscontinuity."
../data/rfc/rfc4670.txt- REFERENCE "RFC 2866 section 3"
../data/rfc/rfc4670.txt- ::= { radiusAccServerExtEntry 10 }
--
../data/rfc/rfc4670.txt- SYNTAX Gauge32
../data/rfc/rfc4670.txt- UNITS "packets"
../data/rfc/rfc4670.txt- MAX-ACCESS read-only
../data/rfc/rfc4670.txt- STATUS current
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt: "The number of RADIUS Accounting-Request packets
../data/rfc/rfc4670.txt- sent to this server that have not yet timed out or
../data/rfc/rfc4670.txt- received a response. This variable is incremented
../data/rfc/rfc4670.txt: when an Accounting-Request is sent and decremented
../data/rfc/rfc4670.txt: due to receipt of an Accounting-Response, a timeout,
../data/rfc/rfc4670.txt- or a retransmission. This counter may experience a
../data/rfc/rfc4670.txt: discontinuity when the RADIUS Accounting Client module
../data/rfc/rfc4670.txt- within the managed entity is reinitialized, as
../data/rfc/rfc4670.txt- indicated by the current value of
../data/rfc/rfc4670.txt- radiusAccClientCounterDiscontinuity."
../data/rfc/rfc4670.txt- REFERENCE "RFC 2866 section 2"
../data/rfc/rfc4670.txt- ::= { radiusAccServerExtEntry 11 }
--
../data/rfc/rfc4670.txt- SYNTAX Counter32
../data/rfc/rfc4670.txt- UNITS "timeouts"
../data/rfc/rfc4670.txt- MAX-ACCESS read-only
../data/rfc/rfc4670.txt- STATUS current
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt: "The number of accounting timeouts to this server.
../data/rfc/rfc4670.txt- After a timeout, the client may retry to the same
../data/rfc/rfc4670.txt- server, send to a different server, or give up.
../data/rfc/rfc4670.txt- A retry to the same server is counted as a
../data/rfc/rfc4670.txt- retransmit as well as a timeout. A send to a different
../data/rfc/rfc4670.txt: server is counted as an Accounting-Request as well as
../data/rfc/rfc4670.txt- a timeout. This counter may experience a discontinuity
../data/rfc/rfc4670.txt: when the RADIUS Accounting Client module within the
../data/rfc/rfc4670.txt- managed entity is reinitialized, as indicated by the
../data/rfc/rfc4670.txt- current value of radiusAccClientCounterDiscontinuity."
../data/rfc/rfc4670.txt- REFERENCE "RFC 2866 section 2"
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-
--
../data/rfc/rfc4670.txt- UNITS "packets"
../data/rfc/rfc4670.txt- MAX-ACCESS read-only
../data/rfc/rfc4670.txt- STATUS current
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt- "The number of RADIUS packets of unknown type that
../data/rfc/rfc4670.txt: were received from this server on the accounting port.
../data/rfc/rfc4670.txt- This counter may experience a discontinuity when the
../data/rfc/rfc4670.txt: RADIUS Accounting Client module within the managed
../data/rfc/rfc4670.txt- entity is reinitialized, as indicated by the current
../data/rfc/rfc4670.txt- value of radiusAccClientCounterDiscontinuity."
../data/rfc/rfc4670.txt- REFERENCE "RFC 2866 section 4"
../data/rfc/rfc4670.txt- ::= { radiusAccServerExtEntry 13 }
../data/rfc/rfc4670.txt-
--
../data/rfc/rfc4670.txt- UNITS "packets"
../data/rfc/rfc4670.txt- MAX-ACCESS read-only
../data/rfc/rfc4670.txt- STATUS current
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt- "The number of RADIUS packets that were received from
../data/rfc/rfc4670.txt: this server on the accounting port and dropped for some
../data/rfc/rfc4670.txt- other reason. This counter may experience a
../data/rfc/rfc4670.txt: discontinuity when the RADIUS Accounting Client module
../data/rfc/rfc4670.txt- within the managed entity is reinitialized, as indicated
../data/rfc/rfc4670.txt- by the current value of
../data/rfc/rfc4670.txt- radiusAccClientCounterDiscontinuity."
../data/rfc/rfc4670.txt- ::= { radiusAccServerExtEntry 14 }
../data/rfc/rfc4670.txt-
--
../data/rfc/rfc4670.txt- UNITS "centiseconds"
../data/rfc/rfc4670.txt- MAX-ACCESS read-only
../data/rfc/rfc4670.txt- STATUS current
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt- "The number of centiseconds since the last
../data/rfc/rfc4670.txt: discontinuity in the RADIUS Accounting Client
../data/rfc/rfc4670.txt- counters. A discontinuity may be the result of a
../data/rfc/rfc4670.txt: reinitialization of the RADIUS Accounting Client
../data/rfc/rfc4670.txt- module within the managed entity."
../data/rfc/rfc4670.txt- ::= { radiusAccServerExtEntry 15 }
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-
--
../data/rfc/rfc4670.txt- -- units of conformance
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- radiusAccClientMIBCompliance MODULE-COMPLIANCE
../data/rfc/rfc4670.txt- STATUS deprecated
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt: "The compliance statement for accounting clients
../data/rfc/rfc4670.txt: implementing the RADIUS Accounting Client MIB.
../data/rfc/rfc4670.txt- Implementation of this module is for IPv4-only
../data/rfc/rfc4670.txt- entities, or for backwards compatibility use with
../data/rfc/rfc4670.txt- entities that support both IPv4 and IPv6."
../data/rfc/rfc4670.txt- MODULE -- this module
../data/rfc/rfc4670.txt- MANDATORY-GROUPS { radiusAccClientMIBGroup }
--
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- radiusAccClientExtMIBCompliance MODULE-COMPLIANCE
../data/rfc/rfc4670.txt- STATUS current
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt: "The compliance statement for accounting
../data/rfc/rfc4670.txt: clients implementing the RADIUS Accounting
../data/rfc/rfc4670.txt- Client IPv6 Extensions MIB. Implementation of
../data/rfc/rfc4670.txt- this module is for entities that support IPv6,
../data/rfc/rfc4670.txt- or support IPv4 and IPv6."
../data/rfc/rfc4670.txt- MODULE -- this module
../data/rfc/rfc4670.txt- MANDATORY-GROUPS { radiusAccClientExtMIBGroup }
--
../data/rfc/rfc4670.txt- radiusAccClientPacketsDropped
../data/rfc/rfc4670.txt- }
../data/rfc/rfc4670.txt- STATUS deprecated
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt- "The basic collection of objects providing management of
../data/rfc/rfc4670.txt: RADIUS Accounting Clients."
../data/rfc/rfc4670.txt- ::= { radiusAccClientMIBGroups 1 }
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- radiusAccClientExtMIBGroup OBJECT-GROUP
../data/rfc/rfc4670.txt- OBJECTS { radiusAccClientIdentifier,
--
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- }
../data/rfc/rfc4670.txt- STATUS current
../data/rfc/rfc4670.txt- DESCRIPTION
../data/rfc/rfc4670.txt- "The basic collection of objects providing management of
../data/rfc/rfc4670.txt: RADIUS Accounting Clients."
../data/rfc/rfc4670.txt- ::= { radiusAccClientMIBGroups 2 }
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- END
../data/rfc/rfc4670.txt-
--
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- There are a number of managed objects in this MIB that may contain
../data/rfc/rfc4670.txt- sensitive information. These are:
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- radiusAcctServerIPAddress
../data/rfc/rfc4670.txt: This can be used to determine the address of the RADIUS accounting
../data/rfc/rfc4670.txt- server with which the client is communicating. This information
../data/rfc/rfc4670.txt: could be useful in mounting an attack on the accounting server.
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- radiusAcctServerInetAddress
../data/rfc/rfc4670.txt: This can be used to determine the address of the RADIUS accounting
../data/rfc/rfc4670.txt- server with which the client is communicating. This information
../data/rfc/rfc4670.txt: could be useful in mounting an attack on the accounting server.
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- radiusAcctClientServerPortNumber
../data/rfc/rfc4670.txt- This can be used to determine the port number on which the RADIUS
../data/rfc/rfc4670.txt: accounting client is sending. This information could be useful in
../data/rfc/rfc4670.txt: impersonating the client in order to send data to the accounting
../data/rfc/rfc4670.txt- server.
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- radiusAcctClientServerInetPortNumber
../data/rfc/rfc4670.txt- This can be used to determine the port number on which the RADIUS
../data/rfc/rfc4670.txt: accounting client is sending. This information could be useful in
../data/rfc/rfc4670.txt: impersonating the client in order to send data to the accounting
../data/rfc/rfc4670.txt- server.
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- It is thus important to control even GET access to these objects and
../data/rfc/rfc4670.txt- possibly to even encrypt the values of these object when sending them
../data/rfc/rfc4670.txt- over the network via SNMP. Not all versions of SNMP provide features
--
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
../data/rfc/rfc4670.txt- "Conformance Statements for SMIv2", STD 58, RFC 2580,
../data/rfc/rfc4670.txt- April 1999.
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
../data/rfc/rfc4670.txt- Architecture for Describing Simple Network Management
../data/rfc/rfc4670.txt- Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
../data/rfc/rfc4670.txt- December 2002.
--
../data/rfc/rfc4670.txt-RFC 4670 RADIUS Acct Client MIB (IPv6) August 2006
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-9.2. Informative References
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt: [RFC2620] Aboba, B. and G. Zorn, "RADIUS Accounting Client MIB",
../data/rfc/rfc4670.txt- RFC 2620, June 1999.
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
../data/rfc/rfc4670.txt- "Remote Authentication Dial In User Service (RADIUS)", RFC
../data/rfc/rfc4670.txt- 2865, June 2000.
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt- [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
../data/rfc/rfc4670.txt- "Introduction and Applicability Statements for Internet-
../data/rfc/rfc4670.txt- Standard Management Framework", RFC 3410, December 2002.
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt: [RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6", RFC
../data/rfc/rfc4670.txt- 4671, August 2006.
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-
../data/rfc/rfc4670.txt-
--
../data/rfc/rfc3423.txt-Request for Comments: 3423 E. Elkin
../data/rfc/rfc3423.txt-Category: Informational XACCT Technologies
../data/rfc/rfc3423.txt- November 2002
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt: XACCT's Common Reliable Accounting for Network Element (CRANE)
../data/rfc/rfc3423.txt- Protocol Specification Version 1.0
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt-Status of this Memo
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- This memo provides information for the Internet community. It does
--
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- Copyright (C) The Internet Society (2002). All Rights Reserved.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt-Abstract
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt: This document defines the Common Reliable Accounting for Network
../data/rfc/rfc3423.txt- Element (CRANE) protocol that enables efficient and reliable delivery
../data/rfc/rfc3423.txt: of any data, mainly accounting data from Network Elements to any
../data/rfc/rfc3423.txt- systems, such as mediation systems and Business Support Systems
../data/rfc/rfc3423.txt- (BSS)/ Operations Support Systems (OSS). The protocol is developed
../data/rfc/rfc3423.txt: to address the critical needs for exporting high volume of accounting
../data/rfc/rfc3423.txt- data from NE's with efficient use of network, storage, and processing
../data/rfc/rfc3423.txt- resources.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- This document specifies the architecture of the protocol and the
../data/rfc/rfc3423.txt- message format, which MUST be supported by all CRANE protocol
--
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt-1 Introduction
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- Network Elements are often required to export usage information to
../data/rfc/rfc3423.txt- mediation and business support systems (BSS) to facilitate
../data/rfc/rfc3423.txt: accounting. Though there are several existing mechanisms for usage
../data/rfc/rfc3423.txt- information export, they are becoming inadequate to support the
../data/rfc/rfc3423.txt- evolving business requirements from service providers.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- For example, some of the export mechanisms are legacies of the Telco
../data/rfc/rfc3423.txt- world. Typically usage information is stored in Network Elements as
--
../data/rfc/rfc3423.txt- of limitations of RADIUS can be found in [3].
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- DIAMETER [2] is a new AAA protocol that retains the basic RADIUS
../data/rfc/rfc3423.txt- model, and eliminates several drawbacks in RADIUS. The current
../data/rfc/rfc3423.txt- DIAMETER protocol and its extensions focus on Internet and wireless
../data/rfc/rfc3423.txt: network access, and their support to accounting is closely associated
../data/rfc/rfc3423.txt- with authentication/authorization events. DIAMETER is intended to
../data/rfc/rfc3423.txt- solve many problems in the AAA area; by doing so, it does not
../data/rfc/rfc3423.txt- adequately address some critical issues such as efficiency and
../data/rfc/rfc3423.txt: performance in an accounting protocol.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- There are also SNMP based mechanisms that generally require a large
../data/rfc/rfc3423.txt- amount of processing and bandwidth resources.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- Based on the above analysis, a critical need for a reliable, fast,
../data/rfc/rfc3423.txt: efficient and flexible accounting protocol exists. The XACCT's CRANE
../data/rfc/rfc3423.txt- protocol is designed to address these critical requirements.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- This document defines the CRANE protocol that enables efficient and
../data/rfc/rfc3423.txt: reliable delivery of any data, mainly accounting data from Network
../data/rfc/rfc3423.txt- Elements to any systems, such as mediation systems and BSS/OSS. The
../data/rfc/rfc3423.txt- protocol is developed to address the critical needs for exporting
../data/rfc/rfc3423.txt: high volume of accounting data from NE's with efficient use of
../data/rfc/rfc3423.txt- network, storage, and processing resources.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- This document specifies the architecture of the protocol and the
../data/rfc/rfc3423.txt- message format, which MUST be supported by all CRANE protocol
../data/rfc/rfc3423.txt- implementations.
--
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt-1.2 Terminology
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- CRANE Protocol
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt: CRANE stands for Common Reliable Accounting for Network Element.
../data/rfc/rfc3423.txt- The CRANE Protocol maybe referred as CRANE, or the Protocol in
../data/rfc/rfc3423.txt- this document. The CRANE Protocol is used at the interface(s)
../data/rfc/rfc3423.txt- between a CRANE client and one or multiple CRANE servers for the
../data/rfc/rfc3423.txt: purpose of delivering accounting data.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt-
--
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- Client or CRANE Client
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- A CRANE Client is an implementation on the data producing side of
../data/rfc/rfc3423.txt- the CRANE protocol. It is typically integrated with the network
../data/rfc/rfc3423.txt: element's software, enabling it to collect and send out accounting
../data/rfc/rfc3423.txt- data to a mediation/billing system using the protocol defined
../data/rfc/rfc3423.txt- herein.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- Server or CRANE Server
../data/rfc/rfc3423.txt-
--
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- CRANE Session
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- A CRANE Session is a logical connection between a CRANE client and
../data/rfc/rfc3423.txt- one or multiple CRANE servers for the purpose of delivering
../data/rfc/rfc3423.txt: accounting data. Multiple sessions MAY be maintained concurrently
../data/rfc/rfc3423.txt- in a CRANE client or a CRANE server; they are distinguished by
../data/rfc/rfc3423.txt- Session IDs.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- Server Priority
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt: A CRANE server is assigned with a Priority value. Accounting data
../data/rfc/rfc3423.txt- is always delivered to the perceived operating CRANE server (from
../data/rfc/rfc3423.txt- the CRANE client point of view) with the highest Priority value
../data/rfc/rfc3423.txt- (the primary server) within a CRANE Session.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- Message
--
../data/rfc/rfc3423.txt- optionally control or user data payload.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- Data Record
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- A Data Record is a collection of information gathered by the
../data/rfc/rfc3423.txt: Network Element for various purposes, e.g., accounting. The
../data/rfc/rfc3423.txt- structure of a Data Record is defined by a Template.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt-
--
../data/rfc/rfc3423.txt- specifies the data type, meaning, and location of the fields in
../data/rfc/rfc3423.txt- the record.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- Data Sequence Number (DSN)
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt: An accounting Data Record level sequence number, which is attached
../data/rfc/rfc3423.txt- to all data messages to facilitate reliable and in-sequence
../data/rfc/rfc3423.txt- delivery.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt-2 Protocol Overview
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt: The CRANE protocol is designed to deliver accounting data reliably,
../data/rfc/rfc3423.txt: efficiently, and quickly. Due to the nature of accounting data,
../data/rfc/rfc3423.txt- large records often need to be transmitted; thus supporting
../data/rfc/rfc3423.txt- fragmentation of large records is required. Furthermore, the value
../data/rfc/rfc3423.txt: associated with accounting data is high; to prevent data loss, quick
../data/rfc/rfc3423.txt- detection of unresponsive CRANE servers is also required for added
../data/rfc/rfc3423.txt- robustness.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- The CRANE protocol can be viewed as an application that uses the data
../data/rfc/rfc3423.txt- transport service provided by lower layer protocols. It relies on a
--
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- 1. Session level authentication.
../data/rfc/rfc3423.txt- 2. Message based data delivery (as opposed to stream based).
../data/rfc/rfc3423.txt- 3. Fast connection failure detection.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt: Reliable delivery of accounting data is achieved through both the
../data/rfc/rfc3423.txt- transport layer level and the CRANE protocol level. The transport
../data/rfc/rfc3423.txt- layer acknowledgments are used to ensure quick detection of lost data
../data/rfc/rfc3423.txt- packets and unresponsive servers, while the CRANE protocol
../data/rfc/rfc3423.txt- acknowledges CRANE messages after they have been processed and the
../data/rfc/rfc3423.txt: accounting information has been placed in persistent storage.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt: Being a reliable protocol for delivering accounting data, traffic
../data/rfc/rfc3423.txt: flowing from a CRANE client to a CRANE server is mostly accounting
../data/rfc/rfc3423.txt- data. There are also bi-directional control message exchanges,
../data/rfc/rfc3423.txt- though they only comprise of small portion of the traffic.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt-
--
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt-2.3 Alternate servers
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- For purposes of improved reliability and robustness, redundant CRANE
../data/rfc/rfc3423.txt- server configuration MAY be employed. The CRANE protocol supports
../data/rfc/rfc3423.txt: delivering accounting data to alternate CRANE servers, which may be
../data/rfc/rfc3423.txt- part of a mediation system or a BSS.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- A CRANE session may comprise of one or more CRANE servers. The CRANE
../data/rfc/rfc3423.txt- client is responsible for configuring network addresses of all CRANE
../data/rfc/rfc3423.txt- servers belonging to the session. A Server Priority is assigned to
../data/rfc/rfc3423.txt- each CRANE server. The Server Priority reflects the CRANE client's
../data/rfc/rfc3423.txt: preference regarding which CRANE server should receive accounting
../data/rfc/rfc3423.txt- data. The assignment of the Server Priority should consider factors
../data/rfc/rfc3423.txt- such as geographical distance, communication cost, and CRANE server
../data/rfc/rfc3423.txt- loading, etc. It is also possible for several CRANE servers to have
../data/rfc/rfc3423.txt- the same priority. In this case, the CRANE client could randomly
../data/rfc/rfc3423.txt: choose one of them as the primary server to deliver accounting data.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt-Zhang & Elkin Informational [Page 7]
../data/rfc/rfc3423.txt-
--
../data/rfc/rfc3423.txt- Additional features such as load balancing may be implemented in a
../data/rfc/rfc3423.txt- multi-server environment. The process of configuring CRANE client is
../data/rfc/rfc3423.txt- carried out using the NE's configuration system and is outside the
../data/rfc/rfc3423.txt- scope of this document.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt: A CRANE client MUST deliver accounting data to its perceived
../data/rfc/rfc3423.txt- operating CRANE server with the highest priority; if this CRANE
../data/rfc/rfc3423.txt- server is deemed unreachable, the CRANE client MUST deliver the
../data/rfc/rfc3423.txt: accounting data to the next highest priority CRANE server that is
../data/rfc/rfc3423.txt- perceived to be operating. If no perceived operating CRANE servers
../data/rfc/rfc3423.txt: are available, accounting data MUST be queued in the CRANE client
../data/rfc/rfc3423.txt- until any CRANE server is available or the client's queue space runs
../data/rfc/rfc3423.txt- out. An alarm should be generated to inform the CRANE user of the
../data/rfc/rfc3423.txt- queue overflow condition.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt: Accounting data delivery SHOULD revert to the higher priority server
../data/rfc/rfc3423.txt- when it is perceived to be operating again.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- The CRANE protocol does not specify how a CRANE client should
../data/rfc/rfc3423.txt: redirect accounting data to other CRANE servers, which is considered
../data/rfc/rfc3423.txt- an implementation issue. But all the supporting mechanisms are
../data/rfc/rfc3423.txt- provided by the protocol to work in a multiple-server environment
../data/rfc/rfc3423.txt- (e.g., the template negotiation process, and configuration
../data/rfc/rfc3423.txt- procedures, etc.). The transport layer (together with some other
../data/rfc/rfc3423.txt- means) is responsible for monitoring server's responsiveness and
--
../data/rfc/rfc3423.txt- issue and should occur under the following conditions:
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- A) Transport layer notifies the CRANE client that the
../data/rfc/rfc3423.txt- corresponding port of the CRANE server is unresponsive.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt: B) Total size of unacknowledged accounting records has exceeded a
../data/rfc/rfc3423.txt- threshold (configurable) for certain duration (configurable).
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- C) A STOP message is received from the active server.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- D) A lower priority server is the active one and a higher priority
--
../data/rfc/rfc3423.txt-RFC 3423 XACCT's CRANE Protocol Specification November 2002
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt-2.4 Templates
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt: The CRANE protocol enables efficient delivery of accounting data.
../data/rfc/rfc3423.txt- This is achieved by negotiating a set of Data Templates for a CRANE
../data/rfc/rfc3423.txt: session before actual accounting data is delivered. A data template
../data/rfc/rfc3423.txt- defines the structure of a DATA message payload by describing the
../data/rfc/rfc3423.txt- data type, meaning, and location of the fields in the payload. By
../data/rfc/rfc3423.txt- agreeing on session templates, CRANE servers understand how to
../data/rfc/rfc3423.txt- process DATA messages received from a CRANE client. As a result, a
../data/rfc/rfc3423.txt: CRANE client only needs to deliver actual accounting data without
../data/rfc/rfc3423.txt- attaching any descriptors of the data; this reduces the amount of
../data/rfc/rfc3423.txt- bytes sent over communication links.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- A template is an ordered list of keys. A key is the specification of
../data/rfc/rfc3423.txt: a field in the template. It specifies an accounting item that a
../data/rfc/rfc3423.txt- network element MAY collect and export. The specification MUST
../data/rfc/rfc3423.txt: consist of the description and the data type of the accounting item.
../data/rfc/rfc3423.txt- (e.g., 'Number of Sent Bytes' can be a key that is an unsigned
../data/rfc/rfc3423.txt- integer of 32 bit long). A CRANE client typically defines keys.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- The CRANE protocol supports usage of several templates concurrently
../data/rfc/rfc3423.txt: (for different accounting records). Keys contained in a template
../data/rfc/rfc3423.txt- could be enabled or disabled. An enabled key implies that the
../data/rfc/rfc3423.txt- outgoing data record will contain the data item specified by the key.
../data/rfc/rfc3423.txt- A disabled key implies that the outgoing record will omit the
../data/rfc/rfc3423.txt- specified data item. The enabling/disabling mechanism further
../data/rfc/rfc3423.txt- reduces bandwidth requirement; it could also reduce processing in
--
../data/rfc/rfc3423.txt- priority within the CRANE session). Each DATA message contains a
../data/rfc/rfc3423.txt- Data Sequence Number (DSN). The primary CRANE server MUST accept the
../data/rfc/rfc3423.txt- data as long as it is in-sequence. Out-of-sequence DATA messages
../data/rfc/rfc3423.txt- should be discarded.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt: The CRANE server detects the start of accounting data when it
../data/rfc/rfc3423.txt- receives the first DATA message either after startup or after a
../data/rfc/rfc3423.txt- server transition. The first DATA message MUST have the 'S' bit
../data/rfc/rfc3423.txt- ('DSN Synchronize' bit) set by the CRANE client. Upon reception of
../data/rfc/rfc3423.txt- the message with initial DSN, the server MUST accept all in-sequence
../data/rfc/rfc3423.txt- DATA messages. The DSN MUST be incremented by 1 for each new DATA
--
../data/rfc/rfc3423.txt- messages. A server MAY issue a STATUS REQ to a CRANE client and
../data/rfc/rfc3423.txt- receive a STATUS RSP message with the requested data.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt-2.9 CRANE Sessions
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt: A CRANE client MAY deliver accounting data to different
../data/rfc/rfc3423.txt- mediation/billing systems by establishing different CRANE sessions.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt-Zhang & Elkin Informational [Page 13]
--
../data/rfc/rfc3423.txt- MUST be incremented by one for each new record transmitted. The
../data/rfc/rfc3423.txt- selection of the initial DSN number is implementation specific.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt- Record Data: Variable Length unsigned octets
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt: The Record Data field carries the actual accounting/billing data
../data/rfc/rfc3423.txt- that is structured according to the template identified by the
../data/rfc/rfc3423.txt- Template ID field.
../data/rfc/rfc3423.txt-
../data/rfc/rfc3423.txt-4.17 Data Acknowledge (DATA ACK)
../data/rfc/rfc3423.txt-
--
../data/rfc/rfc2500.txt--------- Transmission of IPv6 Packets over IPv4 2529*
../data/rfc/rfc2500.txt--------- Reserved IPv6 Subnet Anycast Addresses 2526*
../data/rfc/rfc2500.txt-WEBDAV HTTP Ext. for Distributed Authoring 2518*
../data/rfc/rfc2500.txt-ATM-MIBMAN MIB for ATM Management 2515*
../data/rfc/rfc2500.txt-ATM-TC-OID ATM Textual Conventions and OIDs 2514*
../data/rfc/rfc2500.txt:-------- Connection-Oriented Accounting MIB 2513*
../data/rfc/rfc2500.txt:-------- Accounting Information for ATM Networks 2512*
../data/rfc/rfc2500.txt-X.509-CRMF Internet X.509 CRMF 2511*
../data/rfc/rfc2500.txt-PKICMP Internet X.509 PKI CMP 2510*
../data/rfc/rfc2500.txt-IPCOM-PPP IP Header Compression over PPP 2509*
../data/rfc/rfc2500.txt--------- Compressing IP/UDP/RTP Headers 2508*
../data/rfc/rfc2500.txt--------- IP Header Compression 2507*
--
../data/rfc/rfc2500.txt-
../data/rfc/rfc2500.txt-RFC 2500 Internet Standards June 1999
../data/rfc/rfc2500.txt-
../data/rfc/rfc2500.txt-
../data/rfc/rfc2500.txt-CAST-128 CAST-128 Encryption Algorithm 2144
../data/rfc/rfc2500.txt:RADIUS-ACC RADIUS Accounting 2139
../data/rfc/rfc2500.txt-DLSCAP Data Link Switching Client Access Protocol 2114
../data/rfc/rfc2500.txt-PNG Portable Network Graphics Version 1.0 2083
../data/rfc/rfc2500.txt-RC5 RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms 2040
../data/rfc/rfc2500.txt-SNTP Simple Network Time Protocol v4 for IPv4, IPv6 and OSI 2030
../data/rfc/rfc2500.txt-PGP-MEF PGP Message Exchange Formats 1991
--
../data/rfc/rfc8506.txt- BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
../data/rfc/rfc8506.txt- capitals, as shown here.
../data/rfc/rfc8506.txt-
../data/rfc/rfc8506.txt-1.2. Terminology
../data/rfc/rfc8506.txt-
../data/rfc/rfc8506.txt: AAA: Authentication, Authorization, and Accounting.
../data/rfc/rfc8506.txt-
../data/rfc/rfc8506.txt- AA-Answer: "AA-Answer" generically refers to a service-specific
../data/rfc/rfc8506.txt- authorization and authentication answer. AA-Answer commands are
../data/rfc/rfc8506.txt- defined in service-specific authorization applications, e.g.,
../data/rfc/rfc8506.txt- [RFC7155] [RFC4004].
--
../data/rfc/rfc8506.txt- Capabilities-Exchange-Request and Capabilities-Exchange-Answer
../data/rfc/rfc8506.txt- commands [RFC6733].
../data/rfc/rfc8506.txt-
../data/rfc/rfc8506.txt-2. Architecture Models
../data/rfc/rfc8506.txt-
../data/rfc/rfc8506.txt: The current accounting models specified in the RADIUS accounting and
../data/rfc/rfc8506.txt- Diameter base specifications [RFC2866] [RFC6733] are not sufficient
../data/rfc/rfc8506.txt- for real-time credit-control, where creditworthiness is to be
../data/rfc/rfc8506.txt- determined prior to service initiation. Also, the existing Diameter
../data/rfc/rfc8506.txt- authorization applications [RFC7155] [RFC4004] only provide service
../data/rfc/rfc8506.txt- authorization; they do not provide credit authorization for prepaid
--
../data/rfc/rfc8506.txt-
../data/rfc/rfc8506.txt- A Service Element may authenticate and authorize the end user with
../data/rfc/rfc8506.txt- the AAA server by using AAA protocols, e.g., RADIUS or the Diameter
../data/rfc/rfc8506.txt- base protocol (possibly extended via a Diameter application).
../data/rfc/rfc8506.txt-
../data/rfc/rfc8506.txt: Accounting protocols such as RADIUS accounting and the Diameter base
../data/rfc/rfc8506.txt: accounting protocol can be used to provide accounting data to the
../data/rfc/rfc8506.txt: accounting server after service is initiated and to provide possible
../data/rfc/rfc8506.txt- interim reports until service completion. However, for real-time
../data/rfc/rfc8506.txt: credit-control, these authorization and accounting models are not
../data/rfc/rfc8506.txt- sufficient.
../data/rfc/rfc8506.txt-
../data/rfc/rfc8506.txt- When real-time credit-control is required, the credit-control client
../data/rfc/rfc8506.txt- contacts the credit-control server with information about a possible
../data/rfc/rfc8506.txt- service event. The credit-control process is performed to determine
--
../data/rfc/rfc8506.txt- The Diameter Credit-Control client in the Service Element may get
../data/rfc/rfc8506.txt- information from the authorization server as to whether
../data/rfc/rfc8506.txt- credit-control is required, based on its knowledge of the end user.
../data/rfc/rfc8506.txt- If credit-control is required, the credit-control server needs to be
../data/rfc/rfc8506.txt- contacted prior to initiating service delivery to the end user. The
../data/rfc/rfc8506.txt: accounting protocol and the credit-control protocol can be used in
../data/rfc/rfc8506.txt- parallel. The authorization server may also determine whether the
../data/rfc/rfc8506.txt: parallel accounting stream is required.
../data/rfc/rfc8506.txt-
../data/rfc/rfc8506.txt-
../data/rfc/rfc8506.txt-
../data/rfc/rfc8506.txt-
../data/rfc/rfc8506.txt-
--
../data/rfc/rfc8506.txt- examples are given in Appendix A.
../data/rfc/rfc8506.txt-
../data/rfc/rfc8506.txt- Diameter
../data/rfc/rfc8506.txt- End User Service Element AAA Server CC Server
../data/rfc/rfc8506.txt- (CC Client)
../data/rfc/rfc8506.txt: | Registration | AA-Request/Answer(accounting, CC, or both)|
../data/rfc/rfc8506.txt- |<----------------->|<------------------>| |
../data/rfc/rfc8506.txt- | : | | |
../data/rfc/rfc8506.txt- | : | | |
../data/rfc/rfc8506.txt- | Service Request | | |
../data/rfc/rfc8506.txt- |------------------>| | |
../data/rfc/rfc8506.txt- | | CCR(Initial, Credit-Control AVPs) |
../data/rfc/rfc8506.txt- | +|------------------------------------------>|
../data/rfc/rfc8506.txt- | CC stream|| | CCA(Granted-Units)|
../data/rfc/rfc8506.txt- | +|<------------------------------------------|
../data/rfc/rfc8506.txt- | Service Delivery | | |
../data/rfc/rfc8506.txt: |<----------------->| ACR(start, Accounting AVPs) |
../data/rfc/rfc8506.txt- | : |------------------->|+ |
../data/rfc/rfc8506.txt: | : | ACA || Accounting stream |
../data/rfc/rfc8506.txt- | |<-------------------|+ |
../data/rfc/rfc8506.txt- | : | | |
../data/rfc/rfc8506.txt- | : | | |
../data/rfc/rfc8506.txt- | | CCR(Update, Used-Units) |
../data/rfc/rfc8506.txt- | |------------------------------------------>|
--
../data/rfc/rfc8506.txt- | | ACR(stop) | |
../data/rfc/rfc8506.txt- | |------------------->| |
../data/rfc/rfc8506.txt- | | ACA | |
../data/rfc/rfc8506.txt- | |<-------------------| |
../data/rfc/rfc8506.txt-
../data/rfc/rfc8506.txt: ACR: Accounting-Request
../data/rfc/rfc8506.txt: ACA: Accounting-Answer
../data/rfc/rfc8506.txt-
../data/rfc/rfc8506.txt- Figure 3: Protocol Example with First Interrogation
../data/rfc/rfc8506.txt- after User's Authorization/Authentication
../data/rfc/rfc8506.txt-
../data/rfc/rfc8506.txt-
--
../data/rfc/rfc8506.txt-
../data/rfc/rfc8506.txt-RFC 8506 Diameter Credit-Control Application March 2019
../data/rfc/rfc8506.txt-
../data/rfc/rfc8506.txt-
../data/rfc/rfc8506.txt- Figure 4 illustrates the use of authorization/authentication messages
../data/rfc/rfc8506.txt: to perform the first interrogation. The parallel accounting stream
../data/rfc/rfc8506.txt- is not shown in the figure.
../data/rfc/rfc8506.txt-
../data/rfc/rfc8506.txt- Diameter
../data/rfc/rfc8506.txt- Service Element AAA Server CC Server
../data/rfc/rfc8506.txt- End User (CC Client)
--
../data/rfc/rfc8506.txt-Bertz, et al. Standards Track [Page 41]
../data/rfc/rfc8506.txt-
../data/rfc/rfc8506.txt-RFC 8506 Diameter Credit-Control Application March 2019
../data/rfc/rfc8506.txt-
../data/rfc/rfc8506.txt-
../data/rfc/rfc8506.txt: The authorization server MAY include the Accounting-Realtime-Required
../data/rfc/rfc8506.txt: AVP to determine what to do if the sending of accounting records to
../data/rfc/rfc8506.txt: the accounting server has been temporarily prevented, as defined in
../data/rfc/rfc8506.txt- [RFC6733]. It is RECOMMENDED that the client complement the
../data/rfc/rfc8506.txt: credit-control failure procedures with a backup accounting flow
../data/rfc/rfc8506.txt: toward an accounting server. By using different combinations of the
../data/rfc/rfc8506.txt: Accounting-Realtime-Required AVP and the CCFH, different safety
../data/rfc/rfc8506.txt- levels can be built. For example, by choosing a CCFH equal to
../data/rfc/rfc8506.txt: CONTINUE for the credit-control flow and an Accounting-Realtime-
../data/rfc/rfc8506.txt: Required AVP equal to DELIVER_AND_GRANT for the accounting flow, the
../data/rfc/rfc8506.txt- service can be granted to the end user even if the connection to the
../data/rfc/rfc8506.txt: credit-control server is down, as long as the accounting server is
../data/rfc/rfc8506.txt: able to collect the accounting information and information exchange
../data/rfc/rfc8506.txt: is taking place between the accounting server and credit-control
../data/rfc/rfc8506.txt- server.
../data/rfc/rfc8506.txt-
../data/rfc/rfc8506.txt- As the credit-control application is based on real-time bidirectional
../data/rfc/rfc8506.txt- communication between the credit-control client and the
../data/rfc/rfc8506.txt- credit-control server, the usage of alternative destinations and the
--
../data/rfc/rfc8506.txt- Schooler, "SIP: Session Initiation Protocol", RFC 3261,
../data/rfc/rfc8506.txt- DOI 10.17487/RFC3261, June 2002,
../data/rfc/rfc8506.txt- <https://www.rfc-editor.org/info/rfc3261>.
../data/rfc/rfc8506.txt-
../data/rfc/rfc8506.txt- [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
../data/rfc/rfc8506.txt: Accounting (AAA) Transport Profile", RFC 3539,
../data/rfc/rfc8506.txt- DOI 10.17487/RFC3539, June 2003,
../data/rfc/rfc8506.txt- <https://www.rfc-editor.org/info/rfc3539>.
../data/rfc/rfc8506.txt-
../data/rfc/rfc8506.txt- [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
../data/rfc/rfc8506.txt- Resource Identifier (URI): Generic Syntax", STD 66,
--
../data/rfc/rfc8506.txt-RFC 8506 Diameter Credit-Control Application March 2019
../data/rfc/rfc8506.txt-
../data/rfc/rfc8506.txt-
../data/rfc/rfc8506.txt-16.2. Informative References
../data/rfc/rfc8506.txt-
../data/rfc/rfc8506.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866,
../data/rfc/rfc8506.txt- DOI 10.17487/RFC2866, June 2000,
../data/rfc/rfc8506.txt- <https://www.rfc-editor.org/info/rfc2866>.
../data/rfc/rfc8506.txt-
../data/rfc/rfc8506.txt- [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese,
../data/rfc/rfc8506.txt- "IEEE 802.1X Remote Authentication Dial In User Service
--
../data/rfc/rfc3700.txt--------- Transport Layer Security (TLS) Extensions 3546
../data/rfc/rfc3700.txt--------- Enhanced Compressed RTP (CRTP) for Links with High 3545
../data/rfc/rfc3700.txt- Delay, Packet Loss and Reordering
../data/rfc/rfc3700.txt-IPCOM-PPP IP Header Compression over PPP 3544
../data/rfc/rfc3700.txt--------- Registration Revocation in Mobile IPv4 3543
../data/rfc/rfc3700.txt:-------- Authentication, Authorization and Accounting (AAA) 3539
../data/rfc/rfc3700.txt- Transport Profile
../data/rfc/rfc3700.txt--------- Wrapping a Hashed Message Authentication Code (HMAC) 3537
../data/rfc/rfc3700.txt- key with a Triple-Data Encryption Standard (DES) Key
../data/rfc/rfc3700.txt- or an Advanced Encryption Standard (AES) Key
../data/rfc/rfc3700.txt--------- The application/ogg Media Type 3534
--
../data/rfc/rfc3700.txt-WEBDAV HTTP Extensions for Distributed Authoring -- WEBDAV 2518
../data/rfc/rfc3700.txt-ATM-MIBMAN Definitions of Managed Objects for ATM Management 2515
../data/rfc/rfc3700.txt-ATM-TC-OID Definitions of Textual Conventions and 2514
../data/rfc/rfc3700.txt- OBJECT-IDENTITIES for ATM Management
../data/rfc/rfc3700.txt--------- Managed Objects for Controlling the Collection and 2513
../data/rfc/rfc3700.txt: Storage of Accounting Information for
../data/rfc/rfc3700.txt- Connection-Oriented Networks
../data/rfc/rfc3700.txt:-------- Accounting Information for ATM Networks 2512
../data/rfc/rfc3700.txt-X.509-CRMF Internet X.509 Certificate Request Message Format 2511
../data/rfc/rfc3700.txt-PKICMP Internet X.509 Public Key Infrastructure Certificate 2510
../data/rfc/rfc3700.txt- Management Protocols
../data/rfc/rfc3700.txt--------- Compressing IP/UDP/RTP Headers for Low-Speed Serial 2508
../data/rfc/rfc3700.txt- Links
--
../data/rfc/rfc3700.txt- Control Protocol Transport Mapping
../data/rfc/rfc3700.txt--------- Select and Sort Extensions for the Service Location 3421
../data/rfc/rfc3700.txt- Protocol (SLP)
../data/rfc/rfc3700.txt--------- The Application Exchange (APEX) Presence Service 3343
../data/rfc/rfc3700.txt--------- Dual Stack Hosts Using "Bump-in-the-API" (BIA) 3338
../data/rfc/rfc3700.txt:-------- Policy-Based Accounting 3334
../data/rfc/rfc3700.txt--------- PGM Reliable Transport Protocol Specification 3208
../data/rfc/rfc3700.txt--------- Domain Security Services using S/MIME 3183
../data/rfc/rfc3700.txt-SMX Script MIB Extensibility Protocol Version 1.1 3179
../data/rfc/rfc3700.txt--------- ISO/IEC 9798-3 Authentication SASL Mechanism 3163
../data/rfc/rfc3700.txt-
--
../data/rfc/rfc4365.txt- to attach a remote user or site to a VRF. The authentication
../data/rfc/rfc4365.txt- procedure in this case is part of IPsec, not part of the VPN scheme.
../data/rfc/rfc4365.txt-
../data/rfc/rfc4365.txt- Where L2TP is used, each PPP session carried in an L2TP tunnel can be
../data/rfc/rfc4365.txt- associated with a VRF. The SP's Authentication, Authorization, and
../data/rfc/rfc4365.txt: Accounting (AAA) server can be used to determine the VPN to which the
../data/rfc/rfc4365.txt- PPP session belongs, and then the customer's AAA server can be given
../data/rfc/rfc4365.txt- the opportunity to authenticate that session as well.
../data/rfc/rfc4365.txt-
../data/rfc/rfc4365.txt-6. Security Considerations
../data/rfc/rfc4365.txt-
--
../data/rfc/rfc4365.txt-
../data/rfc/rfc4365.txt- Devices supporting BGP/MPLS IP VPNs that employ the management
../data/rfc/rfc4365.txt- interface characteristics described above will also support the ITU-T
../data/rfc/rfc4365.txt- Telecommunications Management Network Model "FCAPS" functionalities
../data/rfc/rfc4365.txt- as required in the L3VPN Requirements document. These include Fault,
../data/rfc/rfc4365.txt: Configuration, Accounting, Provisioning, and Security.
../data/rfc/rfc4365.txt-
../data/rfc/rfc4365.txt- In BGP/MPLS IP VPNs, the SP is not required to manage the CE devices.
../data/rfc/rfc4365.txt- However, if it is desired for the SP to do so, the SP may manage CE
../data/rfc/rfc4365.txt- devices from a central site, provided that a route to the central
../data/rfc/rfc4365.txt- site is exported into the CE's VPN, and the central site is in a VPN
--
../data/rfc/rfc2094.txt-
../data/rfc/rfc2094.txt- There are some life cycle and security concerns with the software
../data/rfc/rfc2094.txt- while in transit, stored, distributed, and installed. A one time
../data/rfc/rfc2094.txt- start-up procedure must verify the identity of the host. Procedural
../data/rfc/rfc2094.txt- and physical identification techniques will verify the identity of
../data/rfc/rfc2094.txt: the host (i.e., the Armed Forces Courier Service (ARFCS) accounting,
../data/rfc/rfc2094.txt- or registered mail). Upon key delivery the security manager logs
../data/rfc/rfc2094.txt- it's receipt and assumes responsibility for the key.
../data/rfc/rfc2094.txt-
../data/rfc/rfc2094.txt- After proper installation of the software a paper trail verifies the
../data/rfc/rfc2094.txt- recipient. The computer would initiate an association with the
--
../data/rfc/rfc2094.txt- Compromise recovery management If a group member is found
../data/rfc/rfc2094.txt- compromised, the protocol must facilitate the exclusion of the
../data/rfc/rfc2094.txt- compromised member and return to secure operations. The security
../data/rfc/rfc2094.txt- management function will provide control of compromise recovery.
../data/rfc/rfc2094.txt-
../data/rfc/rfc2094.txt: Usually, physical inspections or accounting techniques find
../data/rfc/rfc2094.txt- compromises. These separate systems report the compromise to the key
../data/rfc/rfc2094.txt- management system. We must assume the loss of all key resident at
../data/rfc/rfc2094.txt- that host. The security management function will rescind the
../data/rfc/rfc2094.txt- permission allocated to this compromised host. We create a list of
../data/rfc/rfc2094.txt- all know compromised hosts and distribution that list across the
--
../data/rfc/rfc1017.txt- of link level or end-to-end encryption, or other such methods that
../data/rfc/rfc1017.txt- can be added at a later time. An example of this kind of capability
../data/rfc/rfc1017.txt- would be use of KG-84A link encryptors on MILNET or the Fig Leaf
../data/rfc/rfc1017.txt- DES-based end-to-end encryption box developed by DARPA.
../data/rfc/rfc1017.txt-
../data/rfc/rfc1017.txt:Accounting
../data/rfc/rfc1017.txt-
../data/rfc/rfc1017.txt: The network should provide adequate accounting procedures to track
../data/rfc/rfc1017.txt: the consumption of network resources. Accounting of network
../data/rfc/rfc1017.txt- resources is also important for the management of the network, and
../data/rfc/rfc1017.txt- particularly the management of interconnections with other networks.
../data/rfc/rfc1017.txt: Proper use of the accounting database should allow network management
../data/rfc/rfc1017.txt- personnel to determine the "flows" of data on the network, and the
../data/rfc/rfc1017.txt- identification of bottlenecks in network resources. This capability
../data/rfc/rfc1017.txt- also has secondary value in tracking down intrusions of the network,
../data/rfc/rfc1017.txt- and to provide an audit trail if malicious abuse should occur. In
../data/rfc/rfc1017.txt: addition, accounting of higher level network services (such as
../data/rfc/rfc1017.txt- terminal serving) should be kept track of for the same reasons.
../data/rfc/rfc1017.txt-
../data/rfc/rfc1017.txt-Type of Service Routing
../data/rfc/rfc1017.txt-
../data/rfc/rfc1017.txt- Type of service routing is necessary since not all elements of
--
../data/rfc/rfc1017.txt-Leiner [Page 17]
../data/rfc/rfc1017.txt-
../data/rfc/rfc1017.txt-RFC 1017 Requirements for Scientific Research August 1987
../data/rfc/rfc1017.txt-
../data/rfc/rfc1017.txt-
../data/rfc/rfc1017.txt:Accounting
../data/rfc/rfc1017.txt-
../data/rfc/rfc1017.txt: To permit auditing of usage, accounting information should be
../data/rfc/rfc1017.txt- provided for those resources for which it is deemed necessary. This
../data/rfc/rfc1017.txt- would include identity of the user of the resource and the
../data/rfc/rfc1017.txt- corresponding volume of resource components.
../data/rfc/rfc1017.txt-
../data/rfc/rfc1017.txt-Legalities of Interagency Research Internet
--
../data/rfc/rfc170.txt- Meeting) 22 April 1971 5849 131
../data/rfc/rfc170.txt-White Typographical Error in RFC 107 28 April 1971 6708 132
../data/rfc/rfc170.txt-Sundberg File Transfer and Recovery 27 April 1971 6710 133
../data/rfc/rfc170.txt-Vezza Network Graphics Meeting 29 April 1971 6711 134
../data/rfc/rfc170.txt-Hathaway Response to NWG/RFC 110 29 April 1971 6712 135
../data/rfc/rfc170.txt:Kahn Host Accounting and Administrative
../data/rfc/rfc170.txt- Procedures 29 April 1971 6713 136
../data/rfc/rfc170.txt-O'Sullivan TELNET Protocol -- A Proposed
../data/rfc/rfc170.txt- Document 30 April 1971 6714 137
../data/rfc/rfc170.txt-O'Sullivan TELNET Protocol -- A Proposed
../data/rfc/rfc170.txt- Document (rev.) 8 May 1971 6703 rev 137
--
../data/rfc/rfc7029.txt-
../data/rfc/rfc7029.txt- Consider the following example. A relatively untrusted service, say
../data/rfc/rfc7029.txt- a print server, has been compromised. A user is attempting to
../data/rfc/rfc7029.txt- connect to a trusted service such as a financial application. Both
../data/rfc/rfc7029.txt- the print server and the financial application use an Authentication,
../data/rfc/rfc7029.txt: Authorization, and Accounting protocol (AAA) to transport EAP
../data/rfc/rfc7029.txt- authentication back to the user's EAP server. The print server
../data/rfc/rfc7029.txt- mounts a man-in-the-middle attack on the user's connection to the
../data/rfc/rfc7029.txt- financial application and claims to be the application.
../data/rfc/rfc7029.txt-
../data/rfc/rfc7029.txt- The print server offers a tunnel method towards the peer. The print
--
../data/rfc/rfc4230.txt- when exchanging policy information. Hence, we can assume that
../data/rfc/rfc4230.txt- the policy decision point may use information from an initial
../data/rfc/rfc4230.txt- authentication and key agreement protocol (which may have already
../data/rfc/rfc4230.txt- required cross-realm communication with the user's home domain,
../data/rfc/rfc4230.txt- if only to show that the home domain knows the user and that the
../data/rfc/rfc4230.txt: user is entitled to roam), to forward accounting messages to this
../data/rfc/rfc4230.txt- domain. This represents the traditional subscriber-based
../data/rfc/rfc4230.txt: accounting scenario. Non-traditional or alternative means of
../data/rfc/rfc4230.txt- access might be deployed in the near future that do not require
../data/rfc/rfc4230.txt- any type of inter-domain communication.
../data/rfc/rfc4230.txt-
../data/rfc/rfc4230.txt- Additional discussions are required to determine the expected
../data/rfc/rfc4230.txt- authorization procedures. [34] and [35] discuss authorization
--
../data/rfc/rfc4230.txt-
../data/rfc/rfc4230.txt- [33] Raeburn, K., "Encryption and Checksum Specifications for
../data/rfc/rfc4230.txt- Kerberos 5", RFC 3961, February 2005.
../data/rfc/rfc4230.txt-
../data/rfc/rfc4230.txt- [34] Tschofenig, H., Buechli, M., Van den Bosch, S., and H.
../data/rfc/rfc4230.txt: Schulzrinne, "NSIS Authentication, Authorization and Accounting
../data/rfc/rfc4230.txt- Issues", Work in Progress, March 2003.
../data/rfc/rfc4230.txt-
../data/rfc/rfc4230.txt-
../data/rfc/rfc4230.txt-
../data/rfc/rfc4230.txt-Tschofenig & Graveman Informational [Page 42]
--
../data/rfc/rfc4230.txt- Work in Progress, October 2005.
../data/rfc/rfc4230.txt-
../data/rfc/rfc4230.txt- [41] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
../data/rfc/rfc4230.txt- 4306, November 2005.
../data/rfc/rfc4230.txt-
../data/rfc/rfc4230.txt: [42] Herzog, S., "Accounting and Access Control in RSVP", PhD
../data/rfc/rfc4230.txt- Dissertation, USC, Work in Progress, November 1995.
../data/rfc/rfc4230.txt-
../data/rfc/rfc4230.txt: [43] Herzog, S., "Accounting and Access Control for Multicast
../data/rfc/rfc4230.txt- Distributions: Models and Mechanisms", June 1996.
../data/rfc/rfc4230.txt-
../data/rfc/rfc4230.txt- [44] Pato, J., "Using Pre-Authentication to Avoid Password Guessing
../data/rfc/rfc4230.txt- Attacks", Open Software Foundation DCE Request for Comments,
../data/rfc/rfc4230.txt- December 1992.
--
../data/rfc/rfc6611.txt-
../data/rfc/rfc6611.txt- In the integrated scenario, the bootstrapping of the home agent
../data/rfc/rfc6611.txt- information can be achieved via DHCPv6. This document defines the
../data/rfc/rfc6611.txt- MIPv6 bootstrapping procedures for the integrated scenario. It
../data/rfc/rfc6611.txt- enables home agent assignment in the integrated scenario by utilizing
../data/rfc/rfc6611.txt: DHCP and Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc6611.txt- protocols. The specification utilizes DHCP and AAA options and
../data/rfc/rfc6611.txt- attribute-value pairs (AVPs) that are defined in [RFC6610] and
../data/rfc/rfc6611.txt- [RFC5447]. This document specifies the interworking among Mobile
../data/rfc/rfc6611.txt- Node (MN), Network Access Server (NAS), DHCP, and AAA entities for
../data/rfc/rfc6611.txt- the bootstrapping procedure in the integrated scenario.
--
../data/rfc/rfc7458.txt- protocol is required for mobile devices to access the mobile Evolved
../data/rfc/rfc7458.txt- Packet Core (EPC) via Wi-Fi networks. This document defines a few
../data/rfc/rfc7458.txt- new EAP attributes to enable the above-mentioned functions in such
../data/rfc/rfc7458.txt- networks. The attributes are exchanged between a client (such as a
../data/rfc/rfc7458.txt- Mobile Node (MN)) and its network counterpart (such as an
../data/rfc/rfc7458.txt: Authentication, Authorization, and Accounting (AAA) server) in the
../data/rfc/rfc7458.txt- service provider's infrastructure.
../data/rfc/rfc7458.txt-
../data/rfc/rfc7458.txt-Status of This Memo
../data/rfc/rfc7458.txt-
../data/rfc/rfc7458.txt- This document is not an Internet Standards Track specification; it is
--
../data/rfc/rfc8272.txt-Schmitt, et al. Informational [Page 9]
../data/rfc/rfc8272.txt-
../data/rfc/rfc8272.txt-RFC 8272 TinyIPFIX November 2017
../data/rfc/rfc8272.txt-
../data/rfc/rfc8272.txt-
../data/rfc/rfc8272.txt: Applications that use smart sensors for accounting purposes for long-
../data/rfc/rfc8272.txt- term measurements can benefit from the use of TinyIPFIX. One
../data/rfc/rfc8272.txt- application for IPFIX is long-term monitoring of large physical
../data/rfc/rfc8272.txt- volumes. In [Tolle05], Tolle et al. built a system for monitoring a
../data/rfc/rfc8272.txt- "70-meter tall redwood tree, at a density interval of 5 minutes in
../data/rfc/rfc8272.txt- time and 2 meters in space". The sensor node infrastructure was
--
../data/rfc/rfc8272.txt- combines several TinyIPFIX Messages into a single TinyIPFIX
../data/rfc/rfc8272.txt- Message before forwarding them.
../data/rfc/rfc8272.txt-
../data/rfc/rfc8272.txt- 3. The application must accept potential packet loss. TinyIPFIX
../data/rfc/rfc8272.txt- only fits for applications where metering data is stored for
../data/rfc/rfc8272.txt: accounting purposes and not for applications where the sensor
../data/rfc/rfc8272.txt- data triggers configuration changes or policy decisions, except
../data/rfc/rfc8272.txt- when Message loss is acceptable for some reason.
../data/rfc/rfc8272.txt-
../data/rfc/rfc8272.txt- 4. The application must not require per-message export timestamps
../data/rfc/rfc8272.txt- (e.g., for auditing). TinyIPFIX removes export timestamps,
--
../data/rfc/rfc5772.txt- The routing system should be sufficiently flexible to accommodate the
../data/rfc/rfc5772.txt- continually changing business relationships of the providers and the
../data/rfc/rfc5772.txt- various levels of trustworthiness that they apply to customers and
../data/rfc/rfc5772.txt- partners.
../data/rfc/rfc5772.txt-
../data/rfc/rfc5772.txt: Service providers will need to be involved in accounting for Internet
../data/rfc/rfc5772.txt- usage and monitoring the traffic. They may be involved in government
../data/rfc/rfc5772.txt- action to tax the usage of the Internet, enforce social mores and
../data/rfc/rfc5772.txt- intellectual property rules, or apply surveillance to the traffic to
../data/rfc/rfc5772.txt- detect or prevent crime.
../data/rfc/rfc5772.txt-
--
../data/rfc/rfc5772.txt- At present, there is an almost total lack of effective traffic
../data/rfc/rfc5772.txt- engineering tools, whether in real time for network control or off-
../data/rfc/rfc5772.txt- line for network planning. The routing system should encourage the
../data/rfc/rfc5772.txt- provision of such tools.
../data/rfc/rfc5772.txt-
../data/rfc/rfc5772.txt: R(41) The routing system must generate statistical and accounting
../data/rfc/rfc5772.txt- information in such a way that traffic engineering and network
../data/rfc/rfc5772.txt- planning tools can be used in both real-time and off-line
../data/rfc/rfc5772.txt- planning and management.
../data/rfc/rfc5772.txt-
../data/rfc/rfc5772.txt-3.6.7.2. Support of Multiple Parallel Paths
--
../data/rfc/rfc2205.txt-
../data/rfc/rfc2205.txt- o Policy control
../data/rfc/rfc2205.txt-
../data/rfc/rfc2205.txt- A function that determines whether a new request for quality of
../data/rfc/rfc2205.txt- service has administrative permission to make the requested
../data/rfc/rfc2205.txt: reservation. Policy control may also perform accounting (usage
../data/rfc/rfc2205.txt- feedback) for a reservation.
../data/rfc/rfc2205.txt-
../data/rfc/rfc2205.txt- o Policy data
../data/rfc/rfc2205.txt-
../data/rfc/rfc2205.txt- Data carried in a Path or Resv message and used as input to
--
../data/rfc/rfc409.txt- Note: If the user's login directory name exceeds eight characters in
../data/rfc/rfc409.txt- length, the user must explicitly supply a user name; no default is
../data/rfc/rfc409.txt- available.
../data/rfc/rfc409.txt-
../data/rfc/rfc409.txt- Whenever SMFS interacts with the server process at Santa Barbara on
../data/rfc/rfc409.txt: the user's behalf, it does so with the accounting parameters then in
../data/rfc/rfc409.txt- the accumulators.
../data/rfc/rfc409.txt-
../data/rfc/rfc409.txt-
../data/rfc/rfc409.txt-
../data/rfc/rfc409.txt-
--
../data/rfc/rfc6959.txt- 3.1.1. Single-Packet Attacks ...............................6
../data/rfc/rfc6959.txt- 3.1.2. Flood-Based DoS .....................................7
../data/rfc/rfc6959.txt- 3.1.3. Poisoning Attacks ...................................8
../data/rfc/rfc6959.txt- 3.1.4. Spoof-Based Worm/Malware Propagation ................8
../data/rfc/rfc6959.txt- 3.1.5. Reflective Attacks ..................................8
../data/rfc/rfc6959.txt: 3.1.6. Accounting Subversion ...............................9
../data/rfc/rfc6959.txt- 3.1.7. Other Blind Spoofing Attacks ........................9
../data/rfc/rfc6959.txt- 3.2. Non-blind Attacks ..........................................9
../data/rfc/rfc6959.txt- 3.2.1. Man in the Middle (MITM) ............................9
../data/rfc/rfc6959.txt- 3.2.2. Third-Party Recon ..................................10
../data/rfc/rfc6959.txt- 3.2.3. Other Non-blind Spoofing Attacks ...................10
--
../data/rfc/rfc6959.txt- attacker and generating a large amount of ICMP echo response traffic
../data/rfc/rfc6959.txt- directed towards a target system. These attacks have been
../data/rfc/rfc6959.txt- particularly effective in large campus LAN environments where 50K or
../data/rfc/rfc6959.txt- more hosts might reside on a single subnet.
../data/rfc/rfc6959.txt-
../data/rfc/rfc6959.txt:3.1.6. Accounting Subversion
../data/rfc/rfc6959.txt-
../data/rfc/rfc6959.txt- If an attacker wishes to distribute content or other material in a
../data/rfc/rfc6959.txt- manner that employs protocols that require only unidirectional
../data/rfc/rfc6959.txt- flooding and generate no end-to-end transactional state, they may
../data/rfc/rfc6959.txt- desire to spoof the source IP address of that content in order to
../data/rfc/rfc6959.txt: avoid detection or accounting functions enabled at the IP layer.
../data/rfc/rfc6959.txt- While this particular attack has not been observed, it is included
../data/rfc/rfc6959.txt- here to reflect the range of power that spoofed addresses may have,
../data/rfc/rfc6959.txt- even without the ability to receive responses.
../data/rfc/rfc6959.txt-
../data/rfc/rfc6959.txt-3.1.7. Other Blind Spoofing Attacks
--
../data/rfc/rfc765.txt- the TELNET connections are made (some servers may require
../data/rfc/rfc765.txt- this). Additional identification information in the form of
../data/rfc/rfc765.txt- a password and/or an account command may also be required by
../data/rfc/rfc765.txt- some servers. Servers may allow a new USER command to be
../data/rfc/rfc765.txt- entered at any point in order to change the access control
../data/rfc/rfc765.txt: and/or accounting information. This has the effect of
../data/rfc/rfc765.txt- flushing any user, password, and account information already
../data/rfc/rfc765.txt- supplied and beginning the login sequence again. All
../data/rfc/rfc765.txt- transfer parameters are unchanged and any file transfer in
../data/rfc/rfc765.txt- progress is completed under the old account.
../data/rfc/rfc765.txt-
--
../data/rfc/rfc765.txt-
../data/rfc/rfc765.txt- CHANGE WORKING DIRECTORY (CWD)
../data/rfc/rfc765.txt-
../data/rfc/rfc765.txt- This command allows the user to work with a different
../data/rfc/rfc765.txt- directory or dataset for file storage or retrieval without
../data/rfc/rfc765.txt: altering his login or accounting information. Transfer
../data/rfc/rfc765.txt- parameters are similarly unchanged. The argument is a
../data/rfc/rfc765.txt- pathname specifying a directory or other system dependent
../data/rfc/rfc765.txt- file group designator.
../data/rfc/rfc765.txt-
../data/rfc/rfc765.txt- LIST (LIST)
--
../data/rfc/rfc765.txt- information, such as status or help.
../data/rfc/rfc765.txt-
../data/rfc/rfc765.txt- x2z Connections - Replies referring to the TELNET and data
../data/rfc/rfc765.txt- connections.
../data/rfc/rfc765.txt-
../data/rfc/rfc765.txt: x3z Authentication and accounting - Replies for the login
../data/rfc/rfc765.txt: process and accounting procedures.
../data/rfc/rfc765.txt-
../data/rfc/rfc765.txt- x4z Unspecified as yet
../data/rfc/rfc765.txt-
../data/rfc/rfc765.txt-
../data/rfc/rfc765.txt-
--
../data/rfc/rfc5416.txt- involved in the access policy enforcement portion of the IEEE 802.11
../data/rfc/rfc5416.txt- protocol. The IEEE 802.1X [IEEE.802-1X.2004], Extensible
../data/rfc/rfc5416.txt- Authentication Protocol (EAP) [RFC3748] and IEEE Robust Security
../data/rfc/rfc5416.txt- Network Association (RSNA) Key Management [IEEE.802-11.2007]
../data/rfc/rfc5416.txt- functions are also located on the AC. This implies that the
../data/rfc/rfc5416.txt: Authentication, Authorization, and Accounting (AAA) client also
../data/rfc/rfc5416.txt- resides on the AC.
../data/rfc/rfc5416.txt-
../data/rfc/rfc5416.txt- While the admission control component of IEEE 802.11 resides on the
../data/rfc/rfc5416.txt- AC, the real-time scheduling and queuing functions are on the WTP.
../data/rfc/rfc5416.txt- Note that this does not prevent the AC from providing additional
--
../data/rfc/rfc5841.txt- confused if the payload contains complex philosophical questions that
../data/rfc/rfc5841.txt- make one ponder the meaning of life and one's place in the universe.
../data/rfc/rfc5841.txt-
../data/rfc/rfc5841.txt-4.5. Bored Packets
../data/rfc/rfc5841.txt-
../data/rfc/rfc5841.txt: Packets carrying accounting data with debits, credits, and so on MUST
../data/rfc/rfc5841.txt- be marked as 'bored'.
../data/rfc/rfc5841.txt-
../data/rfc/rfc5841.txt- It could be said that many people consider RFCs boring. Packets
../data/rfc/rfc5841.txt- containing RFC text MAY be marked as 'bored'.
../data/rfc/rfc5841.txt-
--
../data/rfc/rfc3042.txt-
../data/rfc/rfc3042.txt- One could imagine some limited protection against false duplicate
../data/rfc/rfc3042.txt- ACKs for a non-SACK TCP connection, where the TCP sender keeps a
../data/rfc/rfc3042.txt- record of the number of packets transmitted, and recognizes at most
../data/rfc/rfc3042.txt- one acknowledgment per packet to be used for triggering the sending
../data/rfc/rfc3042.txt: of new data. However, this accounting of packets transmitted and
../data/rfc/rfc3042.txt- acknowledged would require additional state and extra complexity at
../data/rfc/rfc3042.txt- the TCP sender, and does not seem necessary.
../data/rfc/rfc3042.txt-
../data/rfc/rfc3042.txt- The most important protection against false duplicate ACKs comes from
../data/rfc/rfc3042.txt- the limited potential of duplicate ACKs in subverting end-to-end
--
../data/rfc/rfc2999.txt-
../data/rfc/rfc2999.txt-2989 Aboba Nov 2000 Criteria for Evaluating AAA
../data/rfc/rfc2999.txt- Protocols for Network Access
../data/rfc/rfc2999.txt-
../data/rfc/rfc2999.txt-This document represents a summary of Authentication, Authorization,
../data/rfc/rfc2999.txt:Accounting (AAA) protocol requirements for network access. This memo
../data/rfc/rfc2999.txt-provides information for the Internet community.
../data/rfc/rfc2999.txt-
../data/rfc/rfc2999.txt-
../data/rfc/rfc2999.txt-
../data/rfc/rfc2999.txt-Ginoza Informational [Page 3]
--
../data/rfc/rfc2999.txt-document specifies an Internet Best Current Practices for the Internet
../data/rfc/rfc2999.txt-Community, and requests discussion and suggestions for improvements.
../data/rfc/rfc2999.txt-
../data/rfc/rfc2999.txt-
../data/rfc/rfc2999.txt-2977 Glass Oct 2000 Mobile IP Authentication,
../data/rfc/rfc2999.txt: Authorization, and Accounting
../data/rfc/rfc2999.txt- Requirements
../data/rfc/rfc2999.txt-
../data/rfc/rfc2999.txt-This document contains the requirements which would have to be supported
../data/rfc/rfc2999.txt-by a AAA service to aid in providing Mobile IP services. This memo
../data/rfc/rfc2999.txt-provides information for the Internet community.
--
../data/rfc/rfc2999.txt-intent of the INFO method is to allow for the carrying of session
../data/rfc/rfc2999.txt-related control information that is generated during a session.
../data/rfc/rfc2999.txt-[STANDARDS TRACK]
../data/rfc/rfc2999.txt-
../data/rfc/rfc2999.txt-
../data/rfc/rfc2999.txt:2975 Aboba Oct 2000 Introduction to Accounting
../data/rfc/rfc2999.txt- Management
../data/rfc/rfc2999.txt-
../data/rfc/rfc2999.txt-This document describes and discusses the issues involved in the design
../data/rfc/rfc2999.txt:of the modern accounting systems. The field of Accounting Management is
../data/rfc/rfc2999.txt-concerned with the collection the collection of resource consumption
../data/rfc/rfc2999.txt-data for the purposes of capacity and trend analysis, cost allocation,
../data/rfc/rfc2999.txt-auditing, and billing. This memo provides information for the Internet
../data/rfc/rfc2999.txt-community.
../data/rfc/rfc2999.txt-
--
../data/rfc/rfc2999.txt-Ginoza Informational [Page 16]
../data/rfc/rfc2999.txt-
../data/rfc/rfc2999.txt-RFC 2999 Summary of 2900-2999 August 2001
../data/rfc/rfc2999.txt-
../data/rfc/rfc2999.txt-
../data/rfc/rfc2999.txt:2924 Brownlee Sep 2000 Accounting Attributes and
../data/rfc/rfc2999.txt- Record Formats
../data/rfc/rfc2999.txt-
../data/rfc/rfc2999.txt-This document summarises Internet Engineering Task Force (IETF) and
../data/rfc/rfc2999.txt-International Telecommunication Union (ITU-T) documents related to
../data/rfc/rfc2999.txt:Accounting. This memo provides information for the Internet community.
../data/rfc/rfc2999.txt-
../data/rfc/rfc2999.txt-
../data/rfc/rfc2999.txt-2923 Lahey Sep 2000 TCP Problems with Path MTU
../data/rfc/rfc2999.txt- Discovery
../data/rfc/rfc2999.txt-
--
../data/rfc/rfc2999.txt-
../data/rfc/rfc2999.txt-2906 Farrell Aug 2000 AAA Authorization Requirements
../data/rfc/rfc2999.txt-
../data/rfc/rfc2999.txt-
../data/rfc/rfc2999.txt-This document specifies the requirements that Authentication
../data/rfc/rfc2999.txt:Authorization Accounting (AAA) protocols must meet in order to support
../data/rfc/rfc2999.txt-authorization services in the Internet. This memo provides information
../data/rfc/rfc2999.txt-for the Internet community.
../data/rfc/rfc2999.txt-
../data/rfc/rfc2999.txt-
../data/rfc/rfc2999.txt-2905 Vollbrecht Aug 2000 AAA Authorization Application
--
../data/rfc/rfc2999.txt-RFC 2999 Summary of 2900-2999 August 2001
../data/rfc/rfc2999.txt-
../data/rfc/rfc2999.txt-
../data/rfc/rfc2999.txt-2903 de Laat Aug 2000 Generic AAA Architecture
../data/rfc/rfc2999.txt-
../data/rfc/rfc2999.txt:This memo proposes an Authentication, Authorization, Accounting (AAA)
../data/rfc/rfc2999.txt-architecture that would incorporate a generic AAA server along with an
../data/rfc/rfc2999.txt-application interface to a set of Application Specific Modules that
../data/rfc/rfc2999.txt-could perform application specific AAA functions. This memo defines an
../data/rfc/rfc2999.txt-Experimental Protocol for the Internet community.
../data/rfc/rfc2999.txt-
--
../data/rfc/rfc5624.txt-
../data/rfc/rfc5624.txt-6. Security Considerations
../data/rfc/rfc5624.txt-
../data/rfc/rfc5624.txt- This document does not raise any security concerns as it only defines
../data/rfc/rfc5624.txt- QoS parameters and does not yet describe how they are exchanged in an
../data/rfc/rfc5624.txt: Authentication, Authorization, and Accounting (AAA) protocol.
../data/rfc/rfc5624.txt- Security considerations are described in documents using this
../data/rfc/rfc5624.txt- specification.
../data/rfc/rfc5624.txt-
../data/rfc/rfc5624.txt-7. Acknowledgements
../data/rfc/rfc5624.txt-
--
../data/rfc/rfc4764.txt- mechanism, EAP-PSK will be able to provide more sophisticated
../data/rfc/rfc4764.txt- services as the need to do so arises.
../data/rfc/rfc4764.txt-
../data/rfc/rfc4764.txt-1.2. Terminology
../data/rfc/rfc4764.txt-
../data/rfc/rfc4764.txt: Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc4764.txt- Please refer to [10] for more details.
../data/rfc/rfc4764.txt-
../data/rfc/rfc4764.txt- AES-128 A block cipher specified in the Advanced Encryption
../data/rfc/rfc4764.txt- Standard [7].
../data/rfc/rfc4764.txt-
--
../data/rfc/rfc4764.txt-
../data/rfc/rfc4764.txt-7.2. Allocation of EXT Type Numbers
../data/rfc/rfc4764.txt-
../data/rfc/rfc4764.txt- EAP-PSK is not intended as a general-purpose protocol, and
../data/rfc/rfc4764.txt- allocations of EXT_Type should not be made for purposes unrelated to
../data/rfc/rfc4764.txt: authentication, authorization, and accounting.
../data/rfc/rfc4764.txt-
../data/rfc/rfc4764.txt- EXT_Type numbers have a range from 1 to 255.
../data/rfc/rfc4764.txt-
../data/rfc/rfc4764.txt-
../data/rfc/rfc4764.txt-
--
../data/rfc/rfc5659.txt-
../data/rfc/rfc5659.txt- o Operations, Administration, and Maintenance (OAM). Note that
../data/rfc/rfc5659.txt- this is synonymous with 'Operations and Maintenance' referred to
../data/rfc/rfc5659.txt- in RFC 5254 [5].
../data/rfc/rfc5659.txt-
../data/rfc/rfc5659.txt: o Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc5659.txt-
../data/rfc/rfc5659.txt- o Security mechanisms
../data/rfc/rfc5659.txt-
../data/rfc/rfc5659.txt- Further security-related architectural considerations are described
../data/rfc/rfc5659.txt- in Section 12.
--
../data/rfc/rfc1498.txt-RFC 1498 On the Naming and Binding of Network Destinations August 1993
../data/rfc/rfc1498.txt-
../data/rfc/rfc1498.txt-
../data/rfc/rfc1498.txt- 1. Service and Users. These are the functions that one uses, and
../data/rfc/rfc1498.txt- the clients that use them. Examples of services are one that
../data/rfc/rfc1498.txt: tells the time of day, one that performs accounting, or one
../data/rfc/rfc1498.txt- that forwards packets. An example of a client is a particular
../data/rfc/rfc1498.txt- desktop computer.
../data/rfc/rfc1498.txt-
../data/rfc/rfc1498.txt- 2. Nodes. These are computers that can run services or user
../data/rfc/rfc1498.txt- programs. Some nodes are clients of the network, while others
--
../data/rfc/rfc5950.txt-
../data/rfc/rfc5950.txt- provide a data reduction mechanism on the information received across
../data/rfc/rfc5950.txt- the MP Reference Points.
../data/rfc/rfc5950.txt-
../data/rfc/rfc5950.txt- The EMF includes functions such as Date and Time, FCAPS (Fault,
../data/rfc/rfc5950.txt: Configuration, Accounting, Performance, and Security) management, and
../data/rfc/rfc5950.txt- Control Plane functions. The EMF provides event message processing,
../data/rfc/rfc5950.txt- data storage, and logging. The management Agent, a component of the
../data/rfc/rfc5950.txt- EMF, converts internal management information (MI signals) into
../data/rfc/rfc5950.txt- Management Application messages and vice versa. The Agent responds
../data/rfc/rfc5950.txt- to Management Application messages from the Message Communication
--
../data/rfc/rfc2099.txt-The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a
../data/rfc/rfc2099.txt-client to access and manipulate electronic mail messages on a server.
../data/rfc/rfc2099.txt-[STANDARDS-TRACK]
../data/rfc/rfc2099.txt-
../data/rfc/rfc2099.txt-
../data/rfc/rfc2099.txt:2059 Rigney Jan 97 RADIUS Accounting
../data/rfc/rfc2099.txt-
../data/rfc/rfc2099.txt:This document describes a protocol for carrying accounting information
../data/rfc/rfc2099.txt:between a Network Access Server and a shared Accounting Server. This
../data/rfc/rfc2099.txt-memo provides information for the Internet community. This memo does
../data/rfc/rfc2099.txt-not specify an Internet standard of any kind.
../data/rfc/rfc2099.txt-
../data/rfc/rfc2099.txt-
../data/rfc/rfc2099.txt-2058 Rigney Jan 97 Remote Authentication Dial In User
--
../data/rfc/rfc5431.txt- [RFC4006]. The request is based on the Diameter extensibility
../data/rfc/rfc5431.txt- discussions in the DIME WG that led to the conclusion that it is
../data/rfc/rfc5431.txt- better to define new Command Codes whenever the ABNF of a command is
../data/rfc/rfc5431.txt- modified by adding, removing, or semantically changing a required AVP
../data/rfc/rfc5431.txt- in order to avoid interoperability problems. The document is
../data/rfc/rfc5431.txt: utilizing authorization and accounting functionality, and the entire
../data/rfc/rfc5431.txt- exchange is related to users utilizing applications that require QoS
../data/rfc/rfc5431.txt- treatment. This approach is consistent with the practice and
../data/rfc/rfc5431.txt- experience gained since the publication of [RFC3588] (see for example
../data/rfc/rfc5431.txt- [RFC5224]), which is now under revision by the DIME Working Group who
../data/rfc/rfc5431.txt- will provide a revised set of recommendations and procedures for IANA
--
../data/rfc/rfc5729.txt- get routed several hops before such non-existent realms are
../data/rfc/rfc5729.txt- discovered, thus creating unnecessary overhead to the routing system
../data/rfc/rfc5729.txt- in general.
../data/rfc/rfc5729.txt-
../data/rfc/rfc5729.txt- The NAI decoration is used in Authentication, Authorization, and
../data/rfc/rfc5729.txt: Accounting (AAA) infrastructures where the Diameter messages are
../data/rfc/rfc5729.txt- transported between the NAS and the Diameter server via one or more
../data/rfc/rfc5729.txt- AAA brokers or Diameter proxies. In this case, the NAS to Diameter
../data/rfc/rfc5729.txt- server AAA communication relies on the security properties of the
../data/rfc/rfc5729.txt- intermediate AAA brokers and Diameter proxies.
../data/rfc/rfc5729.txt-
--
../data/rfc/rfc6734.txt-
../data/rfc/rfc6734.txt- Diameter Attribute-Value Pairs for Cryptographic Key Transport
../data/rfc/rfc6734.txt-
../data/rfc/rfc6734.txt-Abstract
../data/rfc/rfc6734.txt-
../data/rfc/rfc6734.txt: Some Authentication, Authorization, and Accounting (AAA) applications
../data/rfc/rfc6734.txt- require the transport of cryptographic keying material. This
../data/rfc/rfc6734.txt- document specifies a set of Attribute-Value Pairs (AVPs) providing
../data/rfc/rfc6734.txt- native Diameter support of cryptographic key delivery.
../data/rfc/rfc6734.txt-
../data/rfc/rfc6734.txt-Status of This Memo
--
../data/rfc/rfc1671.txt-
../data/rfc/rfc1671.txt- Some remarks about phsysical and logical multicast follow, and it is
../data/rfc/rfc1671.txt- suggested that a model of how IPng will run over ATM is needed.
../data/rfc/rfc1671.txt-
../data/rfc/rfc1671.txt- Finally, the paper suggests that the requirements for policy routing,
../data/rfc/rfc1671.txt: accounting, and security firewalls will in turn require all IPng
../data/rfc/rfc1671.txt- packets to carry a trace of the type of transaction involved as well
../data/rfc/rfc1671.txt- as of their source and destination.
../data/rfc/rfc1671.txt-
../data/rfc/rfc1671.txt-Transition and deployment
../data/rfc/rfc1671.txt-
--
../data/rfc/rfc1671.txt- basic model works.
../data/rfc/rfc1671.txt-
../data/rfc/rfc1671.txt- Similar remarks could be made about X.25, Frame Relay, SMDS etc. but
../data/rfc/rfc1671.txt- ATM is the case with the highest management hype ratio today.
../data/rfc/rfc1671.txt-
../data/rfc/rfc1671.txt:Policy routing and accounting
../data/rfc/rfc1671.txt-
../data/rfc/rfc1671.txt- Unfortunately, this cannot be ignored, however much one would like
../data/rfc/rfc1671.txt- to. Funding agencies want traffic to flow over the lines funded to
../data/rfc/rfc1671.txt- carry it, and they want to know afterwards how much traffic there
../data/rfc/rfc1671.txt: was. Accounting information can also be used for network planning
../data/rfc/rfc1671.txt- and for back-charging.
../data/rfc/rfc1671.txt-
../data/rfc/rfc1671.txt- It is therefore necessary that IPng and its routing procedures allow
../data/rfc/rfc1671.txt- traffic to be routed in a way that depends on its source and
../data/rfc/rfc1671.txt- destination in detail. (As an example, traffic from the Physics
--
../data/rfc/rfc1671.txt- CERN than traffic from any other department.)
../data/rfc/rfc1671.txt-
../data/rfc/rfc1671.txt- A simple approach to this requirement is to insist that IPng must
../data/rfc/rfc1671.txt- support provider-based addressing and routing.
../data/rfc/rfc1671.txt-
../data/rfc/rfc1671.txt: Accounting of traffic is required at the same level of detail (or
../data/rfc/rfc1671.txt- more, for example how much of the traffic is ftp and how much is
../data/rfc/rfc1671.txt- www?).
../data/rfc/rfc1671.txt-
../data/rfc/rfc1671.txt-
../data/rfc/rfc1671.txt-
--
../data/rfc/rfc1671.txt- effective firewalls in routers than IPv4. In particular efficient
../data/rfc/rfc1671.txt- traffic barring based on source and destination addresses and types
../data/rfc/rfc1671.txt- of transaction is needed.
../data/rfc/rfc1671.txt-
../data/rfc/rfc1671.txt- It seems likely that the same features needed to allow policy routing
../data/rfc/rfc1671.txt: and detailed accounting would be needed for improved firewall
../data/rfc/rfc1671.txt- security. It is outside the scope of this document to discuss these
../data/rfc/rfc1671.txt- features in detail, but it seems unlikely that they are limited to
../data/rfc/rfc1671.txt- implementation details in the border routers. Packets will have to
../data/rfc/rfc1671.txt- carry some authenticated trace of the (source, destination,
../data/rfc/rfc1671.txt- transaction) triplet in order to check for unwanted traffic, to allow
../data/rfc/rfc1671.txt: policy-based source routing, and/or to allow detailed accounting.
../data/rfc/rfc1671.txt- Presumably any IPng will carry source and destination identifiers in
../data/rfc/rfc1671.txt- some format in every packet, but identifying the type of transaction,
../data/rfc/rfc1671.txt- or even the individual transaction, is an extra requirement.
../data/rfc/rfc1671.txt-
../data/rfc/rfc1671.txt-Disclaimer and Acknowledgements
--
../data/rfc/rfc7585.txt- | Service Tag | Use |
../data/rfc/rfc7585.txt- +-----------------+-----------------------------------------+
../data/rfc/rfc7585.txt- | aaa+auth | RADIUS Authentication, i.e., traffic as |
../data/rfc/rfc7585.txt- | | defined in [RFC2865] |
../data/rfc/rfc7585.txt- | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
../data/rfc/rfc7585.txt: | aaa+acct | RADIUS Accounting, i.e., traffic as |
../data/rfc/rfc7585.txt- | | defined in [RFC2866] |
../data/rfc/rfc7585.txt- | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
../data/rfc/rfc7585.txt- | aaa+dynauth | RADIUS Dynamic Authorization, i.e., |
../data/rfc/rfc7585.txt- | | traffic as defined in [RFC5176] |
../data/rfc/rfc7585.txt- +-----------------+-----------------------------------------+
--
../data/rfc/rfc7585.txt- SHOULD be done only when manually configured by an administrator.
../data/rfc/rfc7585.txt-
../data/rfc/rfc7585.txt-2.1.1.3.1. Mandatory-to-Implement Mechanism: Trust Roots + NAIRealm
../data/rfc/rfc7585.txt-
../data/rfc/rfc7585.txt- Verification of authority to provide Authentication, Authorization,
../data/rfc/rfc7585.txt: and Accounting (AAA) services over RADIUS/TLS is a two-step process.
../data/rfc/rfc7585.txt-
../data/rfc/rfc7585.txt- Step 1 is the verification of certificate well-formedness and
../data/rfc/rfc7585.txt- validity as per [RFC5280] and whether it was issued from a root
../data/rfc/rfc7585.txt- certificate that is deemed trustworthy by the RADIUS/TLS client.
../data/rfc/rfc7585.txt-
--
../data/rfc/rfc7585.txt-
../data/rfc/rfc7585.txt-3.1. Applicability
../data/rfc/rfc7585.txt-
../data/rfc/rfc7585.txt- Dynamic server discovery as defined in this document is only
../data/rfc/rfc7585.txt- applicable for new AAA transactions and per service (i.e., distinct
../data/rfc/rfc7585.txt: discovery is needed for Authentication, Accounting, and Dynamic
../data/rfc/rfc7585.txt- Authorization) where a RADIUS entity that acts as a forwarding server
../data/rfc/rfc7585.txt- for one or more realms receives a request with a realm for which it
../data/rfc/rfc7585.txt- is not authoritative, and which no explicit next hop is configured.
../data/rfc/rfc7585.txt- It is only applicable for
../data/rfc/rfc7585.txt-
../data/rfc/rfc7585.txt- a. new user sessions, i.e., for the initial Access-Request.
../data/rfc/rfc7585.txt- Subsequent messages concerning this session, for example, Access-
../data/rfc/rfc7585.txt- Challenges and Access-Accepts, use the previously established
../data/rfc/rfc7585.txt- communication channel between client and server.
../data/rfc/rfc7585.txt-
../data/rfc/rfc7585.txt: b. the first accounting ticket for a user session.
../data/rfc/rfc7585.txt-
../data/rfc/rfc7585.txt- c. the first RADIUS DynAuth packet for a user session.
../data/rfc/rfc7585.txt-
../data/rfc/rfc7585.txt-3.2. Configuration Variables
../data/rfc/rfc7585.txt-
--
../data/rfc/rfc7585.txt-
../data/rfc/rfc7585.txt-3.4. Realm to RADIUS Server Resolution Algorithm
../data/rfc/rfc7585.txt-
../data/rfc/rfc7585.txt-3.4.1. Input
../data/rfc/rfc7585.txt-
../data/rfc/rfc7585.txt: For RADIUS Authentication and RADIUS Accounting server discovery,
../data/rfc/rfc7585.txt- input I to the algorithm is the RADIUS User-Name attribute with
../data/rfc/rfc7585.txt- content of the form "user@realm"; the literal "@" sign is the
../data/rfc/rfc7585.txt- separator between a local user identifier within a realm and its
../data/rfc/rfc7585.txt- realm. The use of multiple literal "@" signs in a User-Name is
../data/rfc/rfc7585.txt- strongly discouraged; but if present, the last "@" sign is to be
--
../data/rfc/rfc7585.txt-
../data/rfc/rfc7585.txt- Assignee: IESG <iesg@ietf.org>
../data/rfc/rfc7585.txt-
../data/rfc/rfc7585.txt- Contact: IETF Chair <chair@ietf.org>
../data/rfc/rfc7585.txt-
../data/rfc/rfc7585.txt: Description: Authentication, Accounting, and Dynamic Authorization
../data/rfc/rfc7585.txt- via the RADIUS protocol. These service names are used to
../data/rfc/rfc7585.txt- construct the SRV service labels "_radiustls" and "_radiusdtls"
../data/rfc/rfc7585.txt- for discovery of RADIUS/TLS and RADIUS/DTLS servers, respectively.
../data/rfc/rfc7585.txt-
../data/rfc/rfc7585.txt- Reference: RFC 7585
--
../data/rfc/rfc7585.txt- [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
../data/rfc/rfc7585.txt- "Remote Authentication Dial In User Service (RADIUS)",
../data/rfc/rfc7585.txt- RFC 2865, DOI 10.17487/RFC2865, June 2000,
../data/rfc/rfc7585.txt- <http://www.rfc-editor.org/info/rfc2865>.
../data/rfc/rfc7585.txt-
../data/rfc/rfc7585.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866,
../data/rfc/rfc7585.txt- DOI 10.17487/RFC2866, June 2000,
../data/rfc/rfc7585.txt- <http://www.rfc-editor.org/info/rfc2866>.
../data/rfc/rfc7585.txt-
../data/rfc/rfc7585.txt- [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application
../data/rfc/rfc7585.txt- Service Location Using SRV RRs and the Dynamic Delegation
--
../data/rfc/rfc1672.txt-Network Working Group N. Brownlee
../data/rfc/rfc1672.txt-Request for Comments: 1672 The University of Auckland
../data/rfc/rfc1672.txt-Category: Informational August 1994
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt: Accounting Requirements for IPng
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt-Status of this Memo
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt- This memo provides information for the Internet community. This memo
../data/rfc/rfc1672.txt- does not specify an Internet standard of any kind. Distribution of
--
../data/rfc/rfc1672.txt- IPng area of any ideas expressed within. Comments should be
../data/rfc/rfc1672.txt- submitted to the big-internet@munnari.oz.au mailing list.
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt-Summary
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt: This white paper discusses accounting requirements for IPng. It
../data/rfc/rfc1672.txt: recommends that all IPng packets carry accounting tags, which would
../data/rfc/rfc1672.txt- vary in size. In the simplest case a tag would simply be a voucher
../data/rfc/rfc1672.txt- identifying the party responsible for the packet. At other times tags
../data/rfc/rfc1672.txt: should also carry other higher-level accounting information.
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt-Background
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt: The Internet Accounting Model - described in RFC 1272 - specifies how
../data/rfc/rfc1672.txt: accounting information is structured, and how it is collected for use
../data/rfc/rfc1672.txt: by accounting aplications. The model is very general, with
../data/rfc/rfc1672.txt: accounting variables being defined for various layers of a protocol
../data/rfc/rfc1672.txt- stack. The group's work has so far concentrated on the lower layers,
../data/rfc/rfc1672.txt- but the model can be extended simply by defining the variables
../data/rfc/rfc1672.txt- required, e.g., for session and application layers.
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt- Brian Carpenter [1] suggests that IPng packets should carry
../data/rfc/rfc1672.txt- authenticated (source, destination, transaction) triplets, which
../data/rfc/rfc1672.txt: could be used for policy-based routing and accounting. The following
../data/rfc/rfc1672.txt- sections explain how the transaction field - hereafter called an
../data/rfc/rfc1672.txt: 'accounting tag' - could be used.
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt:Lower-layer (Transport) Accounting
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt- At the lower (network) layers the tag would simply be a voucher. This
../data/rfc/rfc1672.txt- means it is an arbitrary string which identifies the party
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt-Brownlee [Page 1]
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt:RFC 1672 Accounting Requirements for IPng August 1994
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt- responsible, i.e., willing to pay for, a packet. It would initially
../data/rfc/rfc1672.txt- be set by the host which originates the packet, hence at that stage
../data/rfc/rfc1672.txt- the tag would identify the user who sent it.
--
../data/rfc/rfc1672.txt- path. For example:
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt- user - provider tag identifies user
../data/rfc/rfc1672.txt- provider A - provider B tag identifies provider A
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt: The tag could be used by accounting meters to identify the party
../data/rfc/rfc1672.txt- responsible for a traffic flow, without having to deduce this using
../data/rfc/rfc1672.txt: tables of rules. This should considerably simplify accounting for
../data/rfc/rfc1672.txt- transit traffic across intermediate networks.
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt:Higher-layer (Session and Application) Accounting
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt: At higher layers there is a clear need to measure accounting
../data/rfc/rfc1672.txt- variables and communicate them to various points along a packet's
../data/rfc/rfc1672.txt- path, for example an application server may wish to inform a client
../data/rfc/rfc1672.txt- about its usage of resources. A tag containing this information could
../data/rfc/rfc1672.txt- be read by meters at any point along the packet's path for charging
../data/rfc/rfc1672.txt- purposes, and could also be used by the client to inform the user of
../data/rfc/rfc1672.txt- charges incurred.
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt: It would make the collection of accounting data much simpler if this
../data/rfc/rfc1672.txt- information was carried in a standard tag within each packet, rather
../data/rfc/rfc1672.txt- than having different protocols provide this service in differing
../data/rfc/rfc1672.txt- ways.
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt- For 'old' applications which remain unaware of the tag field, a meter
../data/rfc/rfc1672.txt- could be placed at a gateway for the application's host. This
../data/rfc/rfc1672.txt- 'gateway' meter could determine what the application is by watching
../data/rfc/rfc1672.txt- its streams of packets, then set an appropriate value in thir tag
../data/rfc/rfc1672.txt- fields.
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt:Structure of the accounting tag
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt- The two uses of tags outlined above must be able to coexist. Since
../data/rfc/rfc1672.txt- many - indeed most - of the packets will only carry a voucher, it
../data/rfc/rfc1672.txt- seems simplest to keep this as part of the routing tuple (see below).
../data/rfc/rfc1672.txt-
--
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt-Brownlee [Page 2]
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt:RFC 1672 Accounting Requirements for IPng August 1994
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt- If the encryption/digital signature overhead of the second tag proves
../data/rfc/rfc1672.txt- to be too high, it should be possible to combine this with the
../data/rfc/rfc1672.txt- voucher.
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt- The fine detail of this, or at least the way variables are packed
../data/rfc/rfc1672.txt: into the tags, could be standardised by the Accounting Working Group
../data/rfc/rfc1672.txt- in due course. For the purpose of IPng all that is required is the
../data/rfc/rfc1672.txt- ability to carry one or two variable-size objects in every packet.
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt-References
../data/rfc/rfc1672.txt-
--
../data/rfc/rfc1672.txt- Considerations", RFC 1671, CERN, August 1994.
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt-Security Considerations
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt- For IPng to provide reliable transport in a hostile environment,
../data/rfc/rfc1672.txt: routing and accounting information, i.e., the (source, dest,
../data/rfc/rfc1672.txt- network-tag) and (application-tag) tuples, must be tamper-proof.
../data/rfc/rfc1672.txt- Routers and meters which need to use the tuples will need to hold
../data/rfc/rfc1672.txt- appropriate keys for them. Network operators will have to plan
../data/rfc/rfc1672.txt- for this, for example by determining which routers need which
../data/rfc/rfc1672.txt- sets of keys. This will be neccessary in any case for reliable
../data/rfc/rfc1672.txt- policy-based routing, so the extra work required to set up
../data/rfc/rfc1672.txt: accounting meters should be acceptable.
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt-Author's Address
../data/rfc/rfc1672.txt-
../data/rfc/rfc1672.txt- Nevil Brownlee
../data/rfc/rfc1672.txt- Deputy Director
--
../data/rfc/rfc555.txt- require that a user log in to its system with NIC ident and
../data/rfc/rfc555.txt- Id, rather than with host name and password, as it does
../data/rfc/rfc555.txt- currently.
../data/rfc/rfc555.txt-
../data/rfc/rfc555.txt- I emphasize again that Ids have nothing whatsoever to do with
../data/rfc/rfc555.txt: accounting. UCLA-NMC doesn't force the Author to prove his
../data/rfc/rfc555.txt- identity so UCLA has someone to whom it can bill the resources
../data/rfc/rfc555.txt- consumed in processing the Delivery transaction. It does so to
../data/rfc/rfc555.txt- prevent Jim White from authoring a piece of mail and claiming
../data/rfc/rfc555.txt- that Larry Roberts wrote it.
../data/rfc/rfc555.txt-
--
../data/rfc/rfc7268.txt- 7. Acknowledgments ................................................28
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt-1. Introduction
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- In situations where it is desirable to centrally manage
../data/rfc/rfc7268.txt: authentication, authorization, and accounting (AAA) for IEEE 802
../data/rfc/rfc7268.txt- [IEEE-802] networks, deployment of a backend authentication and
../data/rfc/rfc7268.txt: accounting server is desirable. In such situations, it is expected
../data/rfc/rfc7268.txt- that IEEE 802 authenticators will function as AAA clients.
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS)
../data/rfc/rfc7268.txt- Usage Guidelines" [RFC3580] provides guidelines for the use of the
../data/rfc/rfc7268.txt- Remote Authentication Dial-In User Service (RADIUS) within networks
--
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- The Allowed-Called-Station-Id Attribute allows the RADIUS server
../data/rfc/rfc7268.txt- to specify the authenticator MAC addresses and/or networks to
../data/rfc/rfc7268.txt- which the user is allowed to connect. One or more Allowed-Called-
../data/rfc/rfc7268.txt- Station-Id Attributes MAY be included in an Access-Accept, CoA-
../data/rfc/rfc7268.txt: Request, or Accounting-Request packet.
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- The Allowed-Called-Station-Id Attribute can be useful in
../data/rfc/rfc7268.txt- situations where pre-authentication is supported (e.g., IEEE
../data/rfc/rfc7268.txt- 802.11 pre-authentication). In these scenarios, a Called-Station-
../data/rfc/rfc7268.txt- Id Attribute typically will not be included within the Access-
--
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- The EAP-Peer-Id Attribute contains a Peer-Id generated by the EAP
../data/rfc/rfc7268.txt- method. Exactly how this name is used depends on the link layer
../data/rfc/rfc7268.txt- in question. See [RFC5247] for more discussion. The EAP-Peer-Id
../data/rfc/rfc7268.txt- Attribute MAY be included in Access-Request, Access-Accept, and
../data/rfc/rfc7268.txt: Accounting-Request packets. More than one EAP-Peer-Id Attribute
../data/rfc/rfc7268.txt- MUST NOT be included in an Access-Request; one or more EAP-Peer-Id
../data/rfc/rfc7268.txt- Attributes MAY be included in an Access-Accept.
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt-
--
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- The EAP-Server-Id Attribute contains a Server-Id generated by the
../data/rfc/rfc7268.txt- EAP method. Exactly how this name is used depends on the link
../data/rfc/rfc7268.txt- layer in question. See [RFC5247] for more discussion. The EAP-
../data/rfc/rfc7268.txt- Server-Id Attribute is only allowed in Access-Request, Access-
../data/rfc/rfc7268.txt: Accept, and Accounting-Request packets. More than one EAP-Server-
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt-Aboba, et al. Standards Track [Page 8]
../data/rfc/rfc7268.txt-
--
../data/rfc/rfc7268.txt-2.5. Mobility-Domain-Id
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- Description
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- A single Mobility-Domain-Id Attribute MAY be included in an
../data/rfc/rfc7268.txt: Access-Request or Accounting-Request in order to enable the NAS to
../data/rfc/rfc7268.txt- provide the RADIUS server with the Mobility Domain Identifier
../data/rfc/rfc7268.txt- (MDID), defined in Section 8.4.2.49 of [IEEE-802.11]. A summary
../data/rfc/rfc7268.txt- of the Mobility-Domain-Id Attribute format is shown below. The
../data/rfc/rfc7268.txt- fields are transmitted from left to right.
../data/rfc/rfc7268.txt-
--
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt-RFC 7268 RADIUS Attributes for IEEE 802 July 2014
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- Zero or one Network-Id-Name Attribute is permitted within an
../data/rfc/rfc7268.txt: Access-Request, Access-Challenge, Access-Accept or Accounting-
../data/rfc/rfc7268.txt- Request packet. When included within an Access-Request packet,
../data/rfc/rfc7268.txt- the Network-Id-Name Attribute represents a hint of the NID-Name to
../data/rfc/rfc7268.txt- which the Supplicant should be granted access. When included
../data/rfc/rfc7268.txt- within an Access-Accept packet, the Network-Id-Name Attribute
../data/rfc/rfc7268.txt- represents the NID-Name to which the Supplicant is to be granted
../data/rfc/rfc7268.txt: access. When included within an Accounting-Request packet, the
../data/rfc/rfc7268.txt- Network-Id-Name Attribute represents the NID-Name to which the
../data/rfc/rfc7268.txt- Supplicant has been granted access.
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- A summary of the Network-Id-Name Attribute format is shown below.
../data/rfc/rfc7268.txt- The fields are transmitted from left to right.
--
../data/rfc/rfc7268.txt- [IEEE-802.1X]. The acronym "EAPoL" stands for Extensible
../data/rfc/rfc7268.txt- Authentication Protocol over Local Area Network.
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- Zero or more EAPoL-Announcement Attributes are permitted within an
../data/rfc/rfc7268.txt- Access-Request, Access-Accept, Access-Challenge, Access-Reject,
../data/rfc/rfc7268.txt: Accounting-Request, CoA-Request, or Disconnect-Request packet.
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt-
--
../data/rfc/rfc7268.txt- Attributes contain EAPoL-Announcement TLVs that the user sent in
../data/rfc/rfc7268.txt- an EAPoL-Announcement. When included within an Access-Accept,
../data/rfc/rfc7268.txt- Access-Challenge, Access-Reject, CoA-Request or Disconnect-Request
../data/rfc/rfc7268.txt- packet, EAPoL-Announcement Attributes contain EAPoL-Announcement
../data/rfc/rfc7268.txt- TLVs that the NAS is to send to the user in a unicast EAPoL-
../data/rfc/rfc7268.txt: Announcement. When sent within an Accounting-Request packet,
../data/rfc/rfc7268.txt- EAPoL-Announcement Attributes contain EAPoL-Announcement TLVs that
../data/rfc/rfc7268.txt- the NAS has most recently sent to the user in a unicast EAPoL-
../data/rfc/rfc7268.txt- Announcement.
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- A summary of the EAPoL-Announcement Attribute format is shown
--
../data/rfc/rfc7268.txt- unique identifier that, in conjunction with the SSID, encoded
../data/rfc/rfc7268.txt- within the Called-Station-Id Attribute as described in [RFC3580],
../data/rfc/rfc7268.txt- may be used to provide network identification for a subscription
../data/rfc/rfc7268.txt- service provider network (SSPN), as described in Section 8.4.2.94
../data/rfc/rfc7268.txt- of [IEEE-802.11]. Zero or one WLAN-HESSID Attribute is permitted
../data/rfc/rfc7268.txt: within an Access-Request or Accounting-Request packet.
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- A summary of the WLAN-HESSID Attribute format is shown below. The
../data/rfc/rfc7268.txt- fields are transmitted from left to right.
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- 0 1 2 3
--
../data/rfc/rfc7268.txt- Description
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- The WLAN-Venue-Info Attribute identifies the category of venue
../data/rfc/rfc7268.txt- hosting the WLAN, as defined in Section 8.4.1.34 of [IEEE-802.11].
../data/rfc/rfc7268.txt- Zero or more WLAN-Venue-Info Attributes may be included in an
../data/rfc/rfc7268.txt: Access-Request or Accounting-Request.
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt-
--
../data/rfc/rfc7268.txt- Description
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- The WLAN-Venue-Language Attribute is a string encoded by
../data/rfc/rfc7268.txt- ISO-14962-1997 [ISO-14962-1997] that defines the language used in
../data/rfc/rfc7268.txt- the WLAN-Venue-Name Attribute. Zero or more WLAN-Venue-Language
../data/rfc/rfc7268.txt: Attributes may be included in an Access-Request or Accounting-
../data/rfc/rfc7268.txt- Request, and each one indicates the language of the WLAN-Venue-
../data/rfc/rfc7268.txt- Name Attribute that follows it.
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- A summary of the WLAN-Venue-Language Attribute format is shown
../data/rfc/rfc7268.txt- below. The fields are transmitted from left to right.
--
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- The WLAN-Venue-Name Attribute provides additional metadata on the
../data/rfc/rfc7268.txt- Basic Service Set (BSS). For example, this information may be
../data/rfc/rfc7268.txt- used to assist a user in selecting the appropriate BSS with which
../data/rfc/rfc7268.txt- to associate. Zero or more WLAN-Venue-Name Attributes may be
../data/rfc/rfc7268.txt: included in an Access- Request or Accounting-Request in the same
../data/rfc/rfc7268.txt- or different languages.
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- A summary of the WLAN-Venue-Name Attribute format is shown below.
../data/rfc/rfc7268.txt- The fields are transmitted from left to right.
../data/rfc/rfc7268.txt-
--
../data/rfc/rfc7268.txt- disassociated or de-authenticated. This can occur due to policy
../data/rfc/rfc7268.txt- or for reasons related to the user's subscription.
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- A WLAN-Reason-Code Attribute MAY be included within an Access-
../data/rfc/rfc7268.txt- Reject or Disconnect-Request packet, as well as within an
../data/rfc/rfc7268.txt: Accounting-Request packet. Upon receipt of an Access-Reject or
../data/rfc/rfc7268.txt- Disconnect-Request packet containing a WLAN-Reason-Code Attribute,
../data/rfc/rfc7268.txt- the WLAN-Reason-Code value is copied by the Access Point into the
../data/rfc/rfc7268.txt- Reason Code field of a Disassociation or Deauthentication frame
../data/rfc/rfc7268.txt- (see Clauses 8.3.3.4 and 8.3.3.12, respectively, in
../data/rfc/rfc7268.txt- [IEEE-802.11]), which is subsequently transmitted to the Station.
--
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- The WLAN-Pairwise-Cipher Attribute contains information on the
../data/rfc/rfc7268.txt- pairwise ciphersuite used to establish the robust security network
../data/rfc/rfc7268.txt- association (RSNA) between the AP and mobile device. A WLAN-
../data/rfc/rfc7268.txt- Pairwise-Cipher Attribute MAY be included within Access-Request
../data/rfc/rfc7268.txt: and Accounting-Request packets.
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- A summary of the WLAN-Pairwise-Cipher Attribute format is shown
../data/rfc/rfc7268.txt- below. The fields are transmitted from left to right.
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- 0 1 2 3
--
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- The WLAN-Group-Cipher Attribute contains information on the group
../data/rfc/rfc7268.txt- ciphersuite used to establish the robust security network
../data/rfc/rfc7268.txt- association (RSNA) between the AP and mobile device. A WLAN-
../data/rfc/rfc7268.txt- Group-Cipher Attribute MAY be included within Access-Request and
../data/rfc/rfc7268.txt: Accounting-Request packets.
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- A summary of the WLAN-Group-Cipher Attribute format is shown
../data/rfc/rfc7268.txt- below. The fields are transmitted from left to right.
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- 0 1 2 3
--
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- The WLAN-AKM-Suite Attribute contains information on the
../data/rfc/rfc7268.txt- authentication and key management suite used to establish the
../data/rfc/rfc7268.txt- robust security network association (RSNA) between the AP and
../data/rfc/rfc7268.txt- mobile device. A WLAN-AKM-Suite Attribute MAY be included within
../data/rfc/rfc7268.txt: Access-Request and Accounting-Request packets.
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- A summary of the WLAN-AKM-Suite Attribute format is shown below.
../data/rfc/rfc7268.txt- The fields are transmitted from left to right.
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- 0 1 2 3
--
../data/rfc/rfc7268.txt- The WLAN-Group-Mgmt-Cipher Attribute contains information on the
../data/rfc/rfc7268.txt- group management cipher used to establish the robust security
../data/rfc/rfc7268.txt- network association (RSNA) between the AP and mobile device.
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- Zero or one WLAN-Group-Mgmt-Cipher Attribute MAY be included
../data/rfc/rfc7268.txt: within Access-Request and Accounting-Request packets. The
../data/rfc/rfc7268.txt- presence of the Attribute indicates that the Station negotiated to
../data/rfc/rfc7268.txt- use management frame protection during association.
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- A summary of the WLAN-Group-Mgmt-Cipher Attribute format is shown
../data/rfc/rfc7268.txt- below. The fields are transmitted from left to right.
--
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- The WLAN-RF-Band Attribute contains information on the radio
../data/rfc/rfc7268.txt- frequency (RF) band used by the Access Point for transmission and
../data/rfc/rfc7268.txt- reception of information to and from the mobile device. Zero or
../data/rfc/rfc7268.txt- one WLAN-RF-Band Attribute MAY be included within an Access-
../data/rfc/rfc7268.txt: Request or Accounting-Request packet.
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- A summary of the WLAN-RF-Band Attribute format is shown below.
../data/rfc/rfc7268.txt- The fields are transmitted from left to right.
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- 0 1 2 3
--
../data/rfc/rfc7268.txt- 802, no registries are established for maintenance by the IANA.
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt-5. Security Considerations
../data/rfc/rfc7268.txt-
../data/rfc/rfc7268.txt- Since this document describes the use of RADIUS for purposes of
../data/rfc/rfc7268.txt: authentication, authorization, and accounting in IEEE 802 networks,
../data/rfc/rfc7268.txt- it is vulnerable to all of the threats that are present in other
../data/rfc/rfc7268.txt- RADIUS applications. For a discussion of these threats, see
../data/rfc/rfc7268.txt- [RFC2607], [RFC2865], [RFC3162], [RFC3579], [RFC3580], and [RFC5176].
../data/rfc/rfc7268.txt- In particular, when RADIUS traffic is sent in the clear, the
../data/rfc/rfc7268.txt- attributes defined in this document can be obtained by an attacker
--
../data/rfc/rfc4740.txt- 8.9. Registration-Termination-Request (RTR) Command ............39
../data/rfc/rfc4740.txt- 8.10. Registration-Termination-Answer (RTA) Command ............39
../data/rfc/rfc4740.txt- 8.11. Push-Profile-Request (PPR) Command .......................41
../data/rfc/rfc4740.txt- 8.12. Push-Profile-Answer (PPA) Command ........................42
../data/rfc/rfc4740.txt- 9. Diameter SIP Application AVPs ..................................44
../data/rfc/rfc4740.txt: 9.1. SIP-Accounting-Information AVP ............................46
../data/rfc/rfc4740.txt: 9.1.1. SIP-Accounting-Server-URI AVP ......................47
../data/rfc/rfc4740.txt- 9.1.2. SIP-Credit-Control-Server-URI AVP ..................47
../data/rfc/rfc4740.txt- 9.2. SIP-Server-URI AVP ........................................47
../data/rfc/rfc4740.txt- 9.3. SIP-Server-Capabilities AVP ...............................47
../data/rfc/rfc4740.txt- 9.3.1. SIP-Mandatory-Capability AVP .......................48
../data/rfc/rfc4740.txt- 9.3.2. SIP-Optional-Capability AVP ........................48
--
../data/rfc/rfc4740.txt-
../data/rfc/rfc4740.txt- We assume that the SIP server (such as SIP proxy server, registrar,
../data/rfc/rfc4740.txt- redirect server, or alike) and the Diameter client are co-located in
../data/rfc/rfc4740.txt- the same node, so that the SIP server is able to receive and process
../data/rfc/rfc4740.txt- SIP requests and responses. In turn, the SIP server relies on the
../data/rfc/rfc4740.txt: Authentication, Authorization, and Accounting (AAA) infrastructure
../data/rfc/rfc4740.txt- for authenticating the SIP request and authorizing the usage of
../data/rfc/rfc4740.txt- particular SIP services.
../data/rfc/rfc4740.txt-
../data/rfc/rfc4740.txt- This document provides Diameter procedures to implement certain
../data/rfc/rfc4740.txt- required functionality when SIP is the protocol chosen to initiate
--
../data/rfc/rfc4740.txt-
../data/rfc/rfc4740.txt- In another configuration, the address of a SIP outbound proxy is
../data/rfc/rfc4740.txt- configured (by means outside the scope of this specification) into
../data/rfc/rfc4740.txt- the SIP User Agent. The outbound Diameter client in the SIP outbound
../data/rfc/rfc4740.txt- proxy node authenticates the user, requests authorization for SIP
../data/rfc/rfc4740.txt: requests, and performs accounting activities.
../data/rfc/rfc4740.txt-
../data/rfc/rfc4740.txt-6. Overview of Operation
../data/rfc/rfc4740.txt-
../data/rfc/rfc4740.txt- This section provides an informative description of how the Diameter
../data/rfc/rfc4740.txt- SIP application can be used together with SIP. This section is not
--
../data/rfc/rfc4740.txt- mechanism mandated by SIP [RFC3261]. The application is extensible
../data/rfc/rfc4740.txt- and, if need arises, it can be extended to provide support for other
../data/rfc/rfc4740.txt- authentication mechanisms or extensions to HTTP Digest authentication
../data/rfc/rfc4740.txt- when they occur.
../data/rfc/rfc4740.txt-
../data/rfc/rfc4740.txt: This application provides limited support for accounting services as
../data/rfc/rfc4740.txt- follows: the Diameter server is able to provide the addresses of
../data/rfc/rfc4740.txt: accounting severs to the Diameter client. Figure 1, below, shows a
../data/rfc/rfc4740.txt- general overview of the integration of the SIP architecture with the
../data/rfc/rfc4740.txt- AAA architecture.
../data/rfc/rfc4740.txt-
../data/rfc/rfc4740.txt- According to Figure 1, there are one or more SIP User Agents (UAs)
../data/rfc/rfc4740.txt- that initiate or terminate SIP traffic through one or more SIP
--
../data/rfc/rfc4740.txt- { Result-Code }
../data/rfc/rfc4740.txt- { Auth-Session-State }
../data/rfc/rfc4740.txt- { Origin-Host }
../data/rfc/rfc4740.txt- { Origin-Realm }
../data/rfc/rfc4740.txt- * [ SIP-User-Data ]
../data/rfc/rfc4740.txt: [ SIP-Accounting-Information ]
../data/rfc/rfc4740.txt- * [ SIP-Supported-User-Data-Type ]
../data/rfc/rfc4740.txt- [ User-Name ]
../data/rfc/rfc4740.txt- [ Auth-Grace-Period ]
../data/rfc/rfc4740.txt- [ Authorization-Lifetime ]
../data/rfc/rfc4740.txt- [ Redirect-Host ]
--
../data/rfc/rfc4740.txt-
../data/rfc/rfc4740.txt- The Push-Profile-Request (PPR) command is indicated by the
../data/rfc/rfc4740.txt- Command-Code set to 288 and the Command Flags' 'R' bit set. The
../data/rfc/rfc4740.txt- Diameter server sends this command to the Diameter client in a SIP
../data/rfc/rfc4740.txt- server to update either the user profile of an already registered
../data/rfc/rfc4740.txt: user in that SIP server or the SIP accounting information. This
../data/rfc/rfc4740.txt- allows an operator to modify the data of a user profile or the
../data/rfc/rfc4740.txt: accounting information and push it to the SIP server where the user
../data/rfc/rfc4740.txt- is registered.
../data/rfc/rfc4740.txt-
../data/rfc/rfc4740.txt- Each user has a user profile associated with him/her and other
../data/rfc/rfc4740.txt: accounting information. The profile or the accounting information
../data/rfc/rfc4740.txt- may change with time, e.g., due to addition of new services to the
../data/rfc/rfc4740.txt: user. When the user profile or the accounting information changes,
../data/rfc/rfc4740.txt- the Diameter server sends a Diameter Push-Profile-Request (PPR)
../data/rfc/rfc4740.txt- command to the Diameter client in a SIP server, in order to start
../data/rfc/rfc4740.txt- applying those new services.
../data/rfc/rfc4740.txt-
../data/rfc/rfc4740.txt: A PPR command MAY contain a SIP-Accounting-Information AVP that
../data/rfc/rfc4740.txt: updates the addresses of the accounting servers. Changes in the
../data/rfc/rfc4740.txt: addresses of the accounting servers take effect immediately. The
../data/rfc/rfc4740.txt: Diameter client SHOULD close any existing accounting session with the
../data/rfc/rfc4740.txt: existing server and start providing accounting information to the
../data/rfc/rfc4740.txt: newly acquired accounting server.
../data/rfc/rfc4740.txt-
../data/rfc/rfc4740.txt-
../data/rfc/rfc4740.txt-
../data/rfc/rfc4740.txt-Garcia-Martin, et al. Standards Track [Page 41]
../data/rfc/rfc4740.txt-
--
../data/rfc/rfc4740.txt- { Origin-Host }
../data/rfc/rfc4740.txt- { Origin-Realm }
../data/rfc/rfc4740.txt- { Destination-Realm }
../data/rfc/rfc4740.txt- { User-Name }
../data/rfc/rfc4740.txt- * [ SIP-User-Data ]
../data/rfc/rfc4740.txt: [ SIP-Accounting-Information ]
../data/rfc/rfc4740.txt- [ Destination-Host ]
../data/rfc/rfc4740.txt- [ Authorization-Lifetime ]
../data/rfc/rfc4740.txt- [ Auth-Grace-Period ]
../data/rfc/rfc4740.txt- * [ Proxy-Info ]
../data/rfc/rfc4740.txt- * [ Route-Record ]
--
../data/rfc/rfc4740.txt-
../data/rfc/rfc4740.txt- +-----------------------------------+------+----------------+-------+
../data/rfc/rfc4740.txt- | Attribute Name | AVP | Reference | Data- |
../data/rfc/rfc4740.txt- | | Code | | Type |
../data/rfc/rfc4740.txt- +-----------------------------------+------+----------------+-------+
../data/rfc/rfc4740.txt: | SIP-Accounting-Information | 368 | Section 9.1 | G |
../data/rfc/rfc4740.txt: | SIP-Accounting-Server-URI | 369 | Section 9.1.1 | DURI |
../data/rfc/rfc4740.txt- | SIP-Credit-Control-Server-URI | 370 | Section 9.1.2 | DURI |
../data/rfc/rfc4740.txt- | SIP-Server-URI | 371 | Section 9.2 | UTF8S |
../data/rfc/rfc4740.txt- | SIP-Server-Capabilities | 372 | Section 9.3 | G |
../data/rfc/rfc4740.txt- | SIP-Mandatory-Capability | 373 | Section 9.3.1 | U32 |
../data/rfc/rfc4740.txt- | SIP-Optional-Capability | 374 | Section 9.3.2 | U32 |
--
../data/rfc/rfc4740.txt-
../data/rfc/rfc4740.txt- +----------------------------------+------+-----+-----+------+------+
../data/rfc/rfc4740.txt- | Attribute Name | MUST | MAY | SHD | MUST | Encr |
../data/rfc/rfc4740.txt- | | | | NOT | NOT | |
../data/rfc/rfc4740.txt- +----------------------------------+------+-----+-----+------+------+
../data/rfc/rfc4740.txt: | SIP-Accounting-Information | M | P | | V | N |
../data/rfc/rfc4740.txt: | SIP-Accounting-Server-URI | M | P | | V | N |
../data/rfc/rfc4740.txt- | SIP-Credit-Control-Server-URI | M | P | | V | N |
../data/rfc/rfc4740.txt- | SIP-Server-URI | M | P | | V | N |
../data/rfc/rfc4740.txt- | SIP-Server-Capabilities | M | P | | V | N |
../data/rfc/rfc4740.txt- | SIP-Mandatory-Capability | M | P | | V | N |
../data/rfc/rfc4740.txt- | SIP-Optional-Capability | M | P | | V | N |
--
../data/rfc/rfc4740.txt- | SIP-Method | M | P | | V | N |
../data/rfc/rfc4740.txt- +----------------------------------+------+-----+-----+------+------+
../data/rfc/rfc4740.txt-
../data/rfc/rfc4740.txt- Table 3: Summary of the new AVPs flags
../data/rfc/rfc4740.txt-
../data/rfc/rfc4740.txt:9.1. SIP-Accounting-Information AVP
../data/rfc/rfc4740.txt-
../data/rfc/rfc4740.txt: The SIP-Accounting-Information (AVP Code 368) is of type Grouped, and
../data/rfc/rfc4740.txt- contains the Diameter addresses of those nodes that are able to
../data/rfc/rfc4740.txt: collect accounting information.
../data/rfc/rfc4740.txt-
../data/rfc/rfc4740.txt: The SIP-Accounting-Information AVP is defined as follows (per the
../data/rfc/rfc4740.txt- grouped-avp-def of RFC 3588 [RFC3588]):
../data/rfc/rfc4740.txt-
../data/rfc/rfc4740.txt: SIP-Accounting-Information ::= < AVP Header: 368 >
../data/rfc/rfc4740.txt: * [ SIP-Accounting-Server-URI ]
../data/rfc/rfc4740.txt- * [ SIP-Credit-Control-Server-URI ]
../data/rfc/rfc4740.txt- * [ AVP]
../data/rfc/rfc4740.txt-
../data/rfc/rfc4740.txt-
../data/rfc/rfc4740.txt-
--
../data/rfc/rfc4740.txt-Garcia-Martin, et al. Standards Track [Page 46]
../data/rfc/rfc4740.txt-
../data/rfc/rfc4740.txt-RFC 4740 Diameter SIP Application November 2006
../data/rfc/rfc4740.txt-
../data/rfc/rfc4740.txt-
../data/rfc/rfc4740.txt:9.1.1. SIP-Accounting-Server-URI AVP
../data/rfc/rfc4740.txt-
../data/rfc/rfc4740.txt: The SIP-Accounting-Server-URI AVP (AVP Code 369) is of type
../data/rfc/rfc4740.txt- DiameterURI. This AVP contains the address of a Diameter server that
../data/rfc/rfc4740.txt: is able to receive SIP-session-related accounting information.
../data/rfc/rfc4740.txt-
../data/rfc/rfc4740.txt-9.1.2. SIP-Credit-Control-Server-URI AVP
../data/rfc/rfc4740.txt-
../data/rfc/rfc4740.txt- The SIP-Credit-Control-Server-URI AVP (AVP Code 370) is of type
../data/rfc/rfc4740.txt- DiameterURI. This AVP contains the address of a Diameter server that
--
../data/rfc/rfc1789.txt- Section 4);
../data/rfc/rfc1789.txt-
../data/rfc/rfc1789.txt- (i) Handle exceptional conditions, such as long delay or drop of
../data/rfc/rfc1789.txt- voice packets;
../data/rfc/rfc1789.txt-
../data/rfc/rfc1789.txt: (j) Monitor quality of service and keep accounting information.
../data/rfc/rfc1789.txt-
../data/rfc/rfc1789.txt- The above listed functions represent probably the minimal
../data/rfc/rfc1789.txt- requirements for each INETPhone server. Some further important
../data/rfc/rfc1789.txt- features, such as compression/decompression, security, multicasting,
../data/rfc/rfc1789.txt- and voice mail need also to be considered when a real service of
--
../data/rfc/rfc6342.txt- or in the Visited Network.
../data/rfc/rfc6342.txt-
../data/rfc/rfc6342.txt- o The Mobile Network Gateway (MNG): The MNG is the MN's default
../data/rfc/rfc6342.txt- router, which provides IP address management. The MNG performs
../data/rfc/rfc6342.txt- functions such as offering Quality of Service (QoS), applying
../data/rfc/rfc6342.txt: subscriber-specific policy, and enabling billing and accounting;
../data/rfc/rfc6342.txt- these functions are sometimes collectively referred to as
../data/rfc/rfc6342.txt- "subscriber-management" operations. The mobile network
../data/rfc/rfc6342.txt- architecture, as shown in Figure 1, defines the necessary protocol
../data/rfc/rfc6342.txt- interfaces to enable subscriber-management operations. The MNG is
../data/rfc/rfc6342.txt- typically located in the Home Network.
../data/rfc/rfc6342.txt-
../data/rfc/rfc6342.txt- o Border Router (BR): As the name implies, a BR borders the Internet
../data/rfc/rfc6342.txt- for the mobile network. The BR does not perform subscriber
../data/rfc/rfc6342.txt- management for the mobile network.
../data/rfc/rfc6342.txt-
../data/rfc/rfc6342.txt: o Authentication, Authorization, and Accounting (AAA): The general
../data/rfc/rfc6342.txt- functionality of AAA is used for subscriber authentication and
../data/rfc/rfc6342.txt- authorization for services as well as for generating billing and
../data/rfc/rfc6342.txt: accounting information.
../data/rfc/rfc6342.txt-
../data/rfc/rfc6342.txt- In 3GPP network environments, the subscriber authentication and
../data/rfc/rfc6342.txt- the subsequent authorization for connectivity and services is
../data/rfc/rfc6342.txt- provided using the "Home Location Register" (HLR) / "Home
../data/rfc/rfc6342.txt- Subscriber Server" (HSS) functionality.
--
../data/rfc/rfc6342.txt- functionality becomes important.
../data/rfc/rfc6342.txt-
../data/rfc/rfc6342.txt- In addition to the developments cited above, NAT placement is
../data/rfc/rfc6342.txt- important for other reasons as well. Access networks generally need
../data/rfc/rfc6342.txt- to produce network and service usage records for billing and
../data/rfc/rfc6342.txt: accounting. This is true also for mobile networks where "subscriber
../data/rfc/rfc6342.txt: management" features (i.e., QoS, Policy, and Billing and Accounting)
../data/rfc/rfc6342.txt- can be fairly detailed. Since a NAT introduces a binding between two
../data/rfc/rfc6342.txt- addresses, the bindings themselves become necessary information for
../data/rfc/rfc6342.txt- subscriber management. For instance, the offered QoS on private IPv4
../data/rfc/rfc6342.txt- address and the (shared) public IPv4 address may need to be
../data/rfc/rfc6342.txt: correlated for accounting purposes. As another example, the
../data/rfc/rfc6342.txt- Application Servers within the provider network may need to treat
../data/rfc/rfc6342.txt- traffic based on policy provided by the PCRF. If the IP address seen
../data/rfc/rfc6342.txt- by these Application Servers is not unique, the PCRF needs to be able
../data/rfc/rfc6342.txt- to inspect the NAT binding to disambiguate among the individual MNs.
../data/rfc/rfc6342.txt- The subscriber session management information and the service usage
--
../data/rfc/rfc2050.txt- based on administrative convenience.
../data/rfc/rfc2050.txt-
../data/rfc/rfc2050.txt-3.3 Previous Assignment History
../data/rfc/rfc2050.txt-
../data/rfc/rfc2050.txt- To promote increased usage of address space, the registries will
../data/rfc/rfc2050.txt: require an accounting of address space previously assigned to the
../data/rfc/rfc2050.txt- enterprise, if any. In the context of address space allocation, an
../data/rfc/rfc2050.txt- "enterprise" consists of all divisions and/or subsidiaries falling
../data/rfc/rfc2050.txt- under a common parent organization. The previous assignment history
../data/rfc/rfc2050.txt- should include all network numbers assigned to the organization, plus
../data/rfc/rfc2050.txt- the network masks for those networks and the number of hosts on each
--
../data/rfc/rfc7833.txt- named using a Network Access Identifier (NAI) name identifier format.
../data/rfc/rfc7833.txt- Finally, the subject confirmation methods allow requests and queries
../data/rfc/rfc7833.txt- to be issued for a previously authenticated user or machine without
../data/rfc/rfc7833.txt- needing to explicitly identify them as the subject. The use of the
../data/rfc/rfc7833.txt- artifacts defined in this document is not exclusive to ABFAB. They
../data/rfc/rfc7833.txt: can be applied in any Authentication, Authorization, and Accounting
../data/rfc/rfc7833.txt- (AAA) scenario, such as network access control.
../data/rfc/rfc7833.txt-
../data/rfc/rfc7833.txt-Status of This Memo
../data/rfc/rfc7833.txt-
../data/rfc/rfc7833.txt- This is an Internet Standards Track document.
--
../data/rfc/rfc7833.txt- as bindings [OASIS.saml-bindings-2.0-os], which are primarily
../data/rfc/rfc7833.txt- intended for use with the SAML V2.0 web browser single sign-on
../data/rfc/rfc7833.txt- profile [OASIS.saml-profiles-2.0-os]. However, the goal of ABFAB is
../data/rfc/rfc7833.txt- to extend the applicability of federated identity beyond the web to
../data/rfc/rfc7833.txt- other applications by building on the Authentication, Authorization,
../data/rfc/rfc7833.txt: and Accounting (AAA) framework. Consequently, there exists a
../data/rfc/rfc7833.txt- requirement for SAML to integrate with the AAA framework and with
../data/rfc/rfc7833.txt- protocols such as RADIUS [RFC2865] and Diameter [RFC6733], in
../data/rfc/rfc7833.txt- addition to HTTP.
../data/rfc/rfc7833.txt-
../data/rfc/rfc7833.txt-
--
../data/rfc/rfc3251.txt- model, in which the lamps and the distribution network use a
../data/rfc/rfc3251.txt- single control plane.
../data/rfc/rfc3251.txt- 5. RSVP-TE (RSVP with Tariff Extensions) will be used for
../data/rfc/rfc3251.txt- establishing paths for electricity flow in a de-regulated
../data/rfc/rfc3251.txt- environment.
../data/rfc/rfc3251.txt: 6. COPS will be used to support accounting and policy.
../data/rfc/rfc3251.txt-
../data/rfc/rfc3251.txt- After jotting these points down, we felt better. We then noted the
../data/rfc/rfc3251.txt- following immediate advantages of the proposed scheme:
../data/rfc/rfc3251.txt-
../data/rfc/rfc3251.txt- 1. Switches and transformers in the LDS can be replaced by LSRs,
--
../data/rfc/rfc3726.txt- avoids profiling of entities by adversary eavesdropping the signaling
../data/rfc/rfc3726.txt- traffic along the path. The identity used in the process of
../data/rfc/rfc3726.txt- authentication may also be hidden to a limited extent from a network
../data/rfc/rfc3726.txt- to which the initiator is attached. However the identity MUST
../data/rfc/rfc3726.txt- provide enough information for the nodes in the access network to
../data/rfc/rfc3726.txt: collect accounting data.
../data/rfc/rfc3726.txt-
../data/rfc/rfc3726.txt- Network topology hiding MAY be supported to prevent entities along
../data/rfc/rfc3726.txt- the path to learn the topology of a network. Supporting this
../data/rfc/rfc3726.txt- property might conflict with a diagnostic capability.
../data/rfc/rfc3726.txt-
--
../data/rfc/rfc3726.txt- 3) Authorization: It is critical that the NSIS Initiator is
../data/rfc/rfc3726.txt- authorized to perform a QoS path setup.
../data/rfc/rfc3726.txt-
../data/rfc/rfc3726.txt- 4) Accountability: It is important to notice that signaling might be
../data/rfc/rfc3726.txt- used as an entity to charge money for, therefore the
../data/rfc/rfc3726.txt: interoperation with accounting needs to be available.
../data/rfc/rfc3726.txt-
../data/rfc/rfc3726.txt-8.8. QoS Signaling Between PSTN Gateways and Backbone Routers
../data/rfc/rfc3726.txt-
../data/rfc/rfc3726.txt- A PSTN gateway (i.e., host) requires information from the network
../data/rfc/rfc3726.txt- regarding its ability to transport voice traffic across the network.
--
../data/rfc/rfc3726.txt-
../data/rfc/rfc3726.txt-
../data/rfc/rfc3726.txt- aggregate to which the flow must be admitted. In this case, the
../data/rfc/rfc3726.txt- operation of admission control is very similar to the case of the
../data/rfc/rfc3726.txt- PSTN GW with the additional level of indirection imposed by the VPN
../data/rfc/rfc3726.txt: tunnel. Therefore, authentication, accounting and policing may be
../data/rfc/rfc3726.txt- required on the PE router.
../data/rfc/rfc3726.txt-
../data/rfc/rfc3726.txt- In the case of per site signaling, a site would need to be
../data/rfc/rfc3726.txt- identified. This may be accomplished by specifying the network
../data/rfc/rfc3726.txt- serviced at that site through an IP prefix. In this case, the
--
../data/rfc/rfc2722.txt- administering the tariff), incentives (e.g. encouraging off-peak
../data/rfc/rfc2722.txt- use), and cost recovery goals (100% recovery, subsidisation, profit
../data/rfc/rfc2722.txt- making). Issues such as these are not covered here.
../data/rfc/rfc2722.txt-
../data/rfc/rfc2722.txt- Background information explaining why this approach was selected is
../data/rfc/rfc2722.txt: provided by the 'Internet Accounting Background' RFC [ACT-BKG].
../data/rfc/rfc2722.txt-
../data/rfc/rfc2722.txt-
../data/rfc/rfc2722.txt-
../data/rfc/rfc2722.txt-
../data/rfc/rfc2722.txt-
--
../data/rfc/rfc2722.txt- tool for measuring and understanding the network's traffic flows.
../data/rfc/rfc2722.txt- This information is useful for many purposes, as mentioned in section
../data/rfc/rfc2722.txt- 1 (above).
../data/rfc/rfc2722.txt-
../data/rfc/rfc2722.txt- The following sections outline a model for traffic flow measurement,
../data/rfc/rfc2722.txt: which draws from working drafts of the OSI accounting model [OSI-
../data/rfc/rfc2722.txt- ACT].
../data/rfc/rfc2722.txt-
../data/rfc/rfc2722.txt-2.1 Meters and Traffic Flows
../data/rfc/rfc2722.txt-
../data/rfc/rfc2722.txt- At the heart of the traffic measurement model are network entities
--
../data/rfc/rfc2722.txt- address (e.g. an IP port number), any combination of the above, etc,
../data/rfc/rfc2722.txt- depending on the meter's configuration.
../data/rfc/rfc2722.txt-
../data/rfc/rfc2722.txt- We assume that routers or traffic monitors throughout a network are
../data/rfc/rfc2722.txt- instrumented with meters to measure traffic. Issues surrounding the
../data/rfc/rfc2722.txt: choice of meter placement are discussed in the 'Internet Accounting
../data/rfc/rfc2722.txt- Background' RFC [ACT-BKG]. An important aspect of meters is that they
../data/rfc/rfc2722.txt- provide a way of succinctly aggregating traffic information.
../data/rfc/rfc2722.txt-
../data/rfc/rfc2722.txt- For the purpose of traffic flow measurement we define the concept of
../data/rfc/rfc2722.txt- a TRAFFIC FLOW, which is like an artificial logical equivalent to a
--
../data/rfc/rfc2722.txt- notion of ports.
../data/rfc/rfc2722.txt-
../data/rfc/rfc2722.txt- Reporting by adjacent intermediate sources and destinations or simply
../data/rfc/rfc2722.txt- by meter interface (most useful when the meter is embedded in a
../data/rfc/rfc2722.txt- router) supports hierarchical Internet reporting schemes as described
../data/rfc/rfc2722.txt: in the 'Internet Accounting Background' RFC [ACT-BKG]. That is, it
../data/rfc/rfc2722.txt- allows backbone and regional networks to measure usage to just the
../data/rfc/rfc2722.txt- next lower level of granularity (i.e. to the regional and
../data/rfc/rfc2722.txt- stub/enterprise levels, respectively), with the final breakdown
../data/rfc/rfc2722.txt- according to end user (e.g. to source IP address) performed by the
../data/rfc/rfc2722.txt- stub/enterprise networks.
--
../data/rfc/rfc2722.txt- security risks and their countermeasures.
../data/rfc/rfc2722.txt-
../data/rfc/rfc2722.txt-10 Acknowledgments
../data/rfc/rfc2722.txt-
../data/rfc/rfc2722.txt- An initial draft of this document was produced under the auspices
../data/rfc/rfc2722.txt: of the IETF's Internet Accounting Working Group with assistance
../data/rfc/rfc2722.txt- from SNMP, RMON and SAAG working groups. Particular thanks are
../data/rfc/rfc2722.txt- due to Stephen Stibler (IBM Research) for his patient and careful
../data/rfc/rfc2722.txt- comments during the preparation of this memo.
../data/rfc/rfc2722.txt-
../data/rfc/rfc2722.txt-
--
../data/rfc/rfc2722.txt- Local Area Networks - Part 3: Carrier sense multiple
../data/rfc/rfc2722.txt- access with collision detection (CSMA/CD) access method
../data/rfc/rfc2722.txt- and physical layer specifications, 2nd edition, September
../data/rfc/rfc2722.txt- 21, 1990.
../data/rfc/rfc2722.txt-
../data/rfc/rfc2722.txt: [ACT-BKG] Mills, C., Hirsch, G. and G. Ruth, "Internet Accounting
../data/rfc/rfc2722.txt- Background", RFC 1272, November 1991.
../data/rfc/rfc2722.txt-
../data/rfc/rfc2722.txt- [IANA-RFC] Alvestrand, H. and T. Narten, "Guidelines for Writing an
../data/rfc/rfc2722.txt- IANA Considerations Section in RFCs", BCP 26, RFC 2434,
../data/rfc/rfc2722.txt- October 1998.
--
../data/rfc/rfc7340.txt- the P-Asserted-Identity header evolved as part of a broader effort to
../data/rfc/rfc7340.txt- reach parity with traditional telephone network signaling mechanisms
../data/rfc/rfc7340.txt- for selectively sharing and restricting presentation of the calling
../data/rfc/rfc7340.txt- party number at the user level while still allowing core network
../data/rfc/rfc7340.txt- elements to know the identity of the user for abuse prevention and
../data/rfc/rfc7340.txt: accounting.
../data/rfc/rfc7340.txt-
../data/rfc/rfc7340.txt- In order for P-Asserted-Identity to have these properties, it
../data/rfc/rfc7340.txt- requires the existence of a trust domain as described in [RFC3324].
../data/rfc/rfc7340.txt- Any entity in the trust domain may add a P-Asserted-Identity header
../data/rfc/rfc7340.txt- to a SIP message, and any entity in the trust domain may forward a
--
../data/rfc/rfc2382.txt- all the functionality of a router, but such things as MARS and NHRP
../data/rfc/rfc2382.txt- clients would be worthwhile features. A host must manage VCs just
../data/rfc/rfc2382.txt- like any other ATM sender or receiver as described later in section
../data/rfc/rfc2382.txt- 4.
../data/rfc/rfc2382.txt-
../data/rfc/rfc2382.txt:2.6 Accounting and Policy Issues
../data/rfc/rfc2382.txt-
../data/rfc/rfc2382.txt- Since RSVP and IntServ create classes of preferential service, some
../data/rfc/rfc2382.txt- form of administrative control and/or cost allocation is needed to
../data/rfc/rfc2382.txt- control access. There are certain types of policies specific to ATM
../data/rfc/rfc2382.txt- and IP over ATM that need to be studied to determine how they
--
../data/rfc/rfc2382.txt-
../data/rfc/rfc2382.txt- There may be a need for policies specific to IP over ATM. For
../data/rfc/rfc2382.txt- example, since signalling costs in ATM are high relative to IP, an IP
../data/rfc/rfc2382.txt- over ATM specific policy might restrict the ability to change the
../data/rfc/rfc2382.txt- prevailing QoS in a VC. If VCs are relatively scarce, there also
../data/rfc/rfc2382.txt: might be specific accounting costs in creating a new VC. The work so
../data/rfc/rfc2382.txt- far has been preliminary, and much work remains to be done. The
../data/rfc/rfc2382.txt-
../data/rfc/rfc2382.txt-
../data/rfc/rfc2382.txt-
../data/rfc/rfc2382.txt-Crawley, et. al. Informational [Page 11]
--
../data/rfc/rfc990.txt- 1-149 Unassigned [JBP]
../data/rfc/rfc990.txt- 150 Xerox NS IDP [139,HGM]
../data/rfc/rfc990.txt- 151 Unassigned [JBP]
../data/rfc/rfc990.txt- 152 PARC Universal Protocol [15,HGM]
../data/rfc/rfc990.txt- 153 TIP Status Reporting [JGH]
../data/rfc/rfc990.txt: 154 TIP Accounting [JGH]
../data/rfc/rfc990.txt- 155 Internet Protocol [regular] [101,JBP]
../data/rfc/rfc990.txt- 156-158 Internet Protocol [experimental] [101,JBP]
../data/rfc/rfc990.txt- 159 Figleaf Link [JBW1]
../data/rfc/rfc990.txt- 160-194 Unassigned [JBP]
../data/rfc/rfc990.txt- 195 ISO-IP [65,RXM]
--
../data/rfc/rfc592.txt- It is probably reasonably straightforward to define service
../data/rfc/rfc592.txt- interfaces, but they will be useless unless their activating
../data/rfc/rfc592.txt- command languages and other conventions are well documented and
../data/rfc/rfc592.txt- this documentation is kept up to date.
../data/rfc/rfc592.txt-
../data/rfc/rfc592.txt: 5) Accounting
../data/rfc/rfc592.txt-
../data/rfc/rfc592.txt- A very difficult problem once you interconnect systems at lower
../data/rfc/rfc592.txt: levels is to design an appropriate network accounting and banking
../data/rfc/rfc592.txt- system that will not cause undue delays in accessing distributed
../data/rfc/rfc592.txt- resources.
../data/rfc/rfc592.txt-
../data/rfc/rfc592.txt- 6) Error Handling
../data/rfc/rfc592.txt-
--
../data/rfc/rfc6639.txt-4.1. MPLS Management Overview and Requirements
../data/rfc/rfc6639.txt-
../data/rfc/rfc6639.txt- [RFC4378] outlines how data-plane protocols can assist in providing
../data/rfc/rfc6639.txt- the Operations, Administration, and Maintenance (OAM) requirements
../data/rfc/rfc6639.txt- outlined in [RFC4377] and how it is applied to the management
../data/rfc/rfc6639.txt: functions of fault, configuration, accounting, performance, and
../data/rfc/rfc6639.txt- security (commonly known as FCAPS) for MPLS networks.
../data/rfc/rfc6639.txt-
../data/rfc/rfc6639.txt- [RFC4221] describes the management architecture for MPLS. In
../data/rfc/rfc6639.txt- particular, it describes how the managed objects defined in various
../data/rfc/rfc6639.txt- MPLS-related MIB modules model different aspects of MPLS, as well as
--
../data/rfc/rfc1244.txt- managed and physically secured. Links outside a site were unusual.
../data/rfc/rfc1244.txt- Computer security threats were rare, and were basically concerned
../data/rfc/rfc1244.txt- with insiders: authorized users misusing accounts, theft and
../data/rfc/rfc1244.txt- vandalism, and so forth. These threats were well understood and
../data/rfc/rfc1244.txt- dealt with using standard techniques: computers behind locked doors,
../data/rfc/rfc1244.txt: and accounting for all resources.
../data/rfc/rfc1244.txt-
../data/rfc/rfc1244.txt- Computing in the 1990's is radically different. Many systems are in
../data/rfc/rfc1244.txt- private offices and labs, often managed by individuals or persons
../data/rfc/rfc1244.txt- employed outside a computer center. Many systems are connected into
../data/rfc/rfc1244.txt- the Internet, and from there around the world: the United States,
--
../data/rfc/rfc1244.txt- A week later you find that your system initialization
../data/rfc/rfc1244.txt- files had been altered in a hostile fashion.
../data/rfc/rfc1244.txt-
../data/rfc/rfc1244.txt- - You receive a call saying that a breakin to a government
../data/rfc/rfc1244.txt- lab occurred from one of your center's machines. You
../data/rfc/rfc1244.txt: are requested to provide accounting files to help
../data/rfc/rfc1244.txt- trackdown the attacker.
../data/rfc/rfc1244.txt-
../data/rfc/rfc1244.txt- A week later you are given a list of machines at your
../data/rfc/rfc1244.txt- site that have been broken into.
../data/rfc/rfc1244.txt-
--
../data/rfc/rfc1244.txt- right set of controls. If the major threat to your system is
../data/rfc/rfc1244.txt- outside penetrators, it probably doesn't make much sense to use
../data/rfc/rfc1244.txt- biometric devices to authenticate your regular system users. On
../data/rfc/rfc1244.txt- the other hand, if the major threat is unauthorized use of
../data/rfc/rfc1244.txt- computing resources by regular system users, you'll probably want
../data/rfc/rfc1244.txt: to establish very rigorous automated accounting procedures.
../data/rfc/rfc1244.txt-
../data/rfc/rfc1244.txt- 3.3.2 Use Common Sense
../data/rfc/rfc1244.txt-
../data/rfc/rfc1244.txt- Common sense is the most appropriate tool that can be used to
../data/rfc/rfc1244.txt- establish your security policy. Elaborate security schemes and
--
../data/rfc/rfc1244.txt- login histories. Most users typically log in and out
../data/rfc/rfc1244.txt- at roughly the same time each day. An account logged
../data/rfc/rfc1244.txt- in outside the "normal" time for the account may be in
../data/rfc/rfc1244.txt- use by an intruder.
../data/rfc/rfc1244.txt-
../data/rfc/rfc1244.txt: - Many systems maintain accounting records for billing
../data/rfc/rfc1244.txt- purposes. These records can also be used to determine
../data/rfc/rfc1244.txt: usage patterns for the system; unusual accounting records
../data/rfc/rfc1244.txt- may indicate unauthorized use of the system.
../data/rfc/rfc1244.txt-
../data/rfc/rfc1244.txt- - System logging facilities, such as the UNIX "syslog"
../data/rfc/rfc1244.txt- utility, should be checked for unusual error messages
../data/rfc/rfc1244.txt- from system software. For example, a large number of
--
../data/rfc/rfc1244.txt- has unexplainedly been created), or high activity on
../data/rfc/rfc1244.txt- an account that has had virtually no activity for
../data/rfc/rfc1244.txt- months.
../data/rfc/rfc1244.txt- o New files (usually with novel or strange file names,
../data/rfc/rfc1244.txt- such as data.xx or k).
../data/rfc/rfc1244.txt: o Accounting discrepancies (e.g., in a UNIX system you
../data/rfc/rfc1244.txt: might notice that the accounting file called
../data/rfc/rfc1244.txt- /usr/admin/lastlog has shrunk, something that should
../data/rfc/rfc1244.txt- make you very suspicious that there may be an
../data/rfc/rfc1244.txt- intruder).
../data/rfc/rfc1244.txt- o Changes in file lengths or dates (e.g., a user should
../data/rfc/rfc1244.txt- be suspicious if he/she observes that the .EXE files in
--
../data/rfc/rfc1244.txt- the POC may be able to speak for the site in court. The
../data/rfc/rfc1244.txt- alternative is to have multiple witnesses that will be hard to
../data/rfc/rfc1244.txt- coordinate in a legal sense, and will weaken any case against the
../data/rfc/rfc1244.txt- attackers. A single POC may also be the single person in charge
../data/rfc/rfc1244.txt- of evidence collected, which will keep the number of people
../data/rfc/rfc1244.txt: accounting for evidence to a minimum. As a rule of thumb, the
../data/rfc/rfc1244.txt- more people that touch a potential piece of evidence, the greater
../data/rfc/rfc1244.txt- the possibility that it will be inadmissible in court. The
../data/rfc/rfc1244.txt- section below (Legal/Investigative) will provide more details for
../data/rfc/rfc1244.txt- consideration on this topic.
../data/rfc/rfc1244.txt-
--
../data/rfc/rfc1244.txt- some of the insight as to the nature of the incident, and aid
../data/rfc/rfc1244.txt- investigation and prosecution. It is best to compare previous
../data/rfc/rfc1244.txt- backups or original tapes when possible; advance preparation is
../data/rfc/rfc1244.txt- the key. If the system supports centralized logging (most do), go
../data/rfc/rfc1244.txt- back over the logs and look for abnormalities. If process
../data/rfc/rfc1244.txt: accounting and connect time accounting is enabled, look for
../data/rfc/rfc1244.txt- patterns of system usage. To a lesser extent, disk usage may shed
../data/rfc/rfc1244.txt: light on the incident. Accounting can provide much helpful
../data/rfc/rfc1244.txt- information in an analysis of an incident and subsequent
../data/rfc/rfc1244.txt- prosecution.
../data/rfc/rfc1244.txt-
../data/rfc/rfc1244.txt- 6.2.2 Cleanup
../data/rfc/rfc1244.txt-
--
../data/rfc/rfc1244.txt-
../data/rfc/rfc1244.txt- A Cornell University Report presented to the Provost of the
../data/rfc/rfc1244.txt- University on 6 February 1989 on the Internet Worm.
../data/rfc/rfc1244.txt-
../data/rfc/rfc1244.txt- [GAO]
../data/rfc/rfc1244.txt: U.S. General Accounting Office, "Computer Security - Virus
../data/rfc/rfc1244.txt- Highlights Need for Improved Internet Management", United
../data/rfc/rfc1244.txt: States General Accounting Office, Washington, DC, 1989.
../data/rfc/rfc1244.txt-
../data/rfc/rfc1244.txt- This 36 page report (GAO/IMTEC-89-57), by the U.S.
../data/rfc/rfc1244.txt: Government Accounting Office, describes the Internet worm
../data/rfc/rfc1244.txt- and its effects. It gives a good overview of the various
../data/rfc/rfc1244.txt- U.S. agencies involved in the Internet today and their
../data/rfc/rfc1244.txt- concerns vis-a-vis computer security and networking.
../data/rfc/rfc1244.txt-
../data/rfc/rfc1244.txt- Available on-line on host nnsc.nsf.net, directory
--
../data/rfc/rfc1244.txt- NCSC, "A Guide to Understanding CONFIGURATION MANAGEMENT
../data/rfc/rfc1244.txt- in Trusted Systems", NCSC-TG-006, Version-1, 28 March 1988,
../data/rfc/rfc1244.txt- 31 pages.
../data/rfc/rfc1244.txt-
../data/rfc/rfc1244.txt- Configuration management consists of four separate tasks:
../data/rfc/rfc1244.txt: identification, control, status accounting, and auditing.
../data/rfc/rfc1244.txt- For every change that is made to an automated data
../data/rfc/rfc1244.txt- processing (ADP) system, the design and requirements of the
../data/rfc/rfc1244.txt- changed version of the system should be identified. The
../data/rfc/rfc1244.txt- control task of configuration management is performed
../data/rfc/rfc1244.txt- by subjecting every change to documentation, hardware, and
../data/rfc/rfc1244.txt- software/firmware to review and approval by an authorized
../data/rfc/rfc1244.txt: authority. Configuration status accounting is responsible
../data/rfc/rfc1244.txt- for recording and reporting on the configuration of the
../data/rfc/rfc1244.txt- product throughout the change. Finally, though the process
../data/rfc/rfc1244.txt- of a configuration audit, the completed change can be
../data/rfc/rfc1244.txt- verified to be functionally correct, and for trusted
../data/rfc/rfc1244.txt- systems, consistent with the security policy of the system.
--
../data/rfc/rfc6613.txt- A device that provides an access service for a user to a network.
../data/rfc/rfc6613.txt- Also referred to as a Network Access Server, or NAS.
../data/rfc/rfc6613.txt-
../data/rfc/rfc6613.txt- RADIUS server
../data/rfc/rfc6613.txt- A device that provides one or more of authentication,
../data/rfc/rfc6613.txt: authorization, and/or accounting (AAA) services to a NAS.
../data/rfc/rfc6613.txt-
../data/rfc/rfc6613.txt- RADIUS proxy
../data/rfc/rfc6613.txt- A RADIUS proxy acts as a RADIUS server to the NAS, and a RADIUS
../data/rfc/rfc6613.txt- client to the RADIUS server.
../data/rfc/rfc6613.txt-
../data/rfc/rfc6613.txt- RADIUS request packet
../data/rfc/rfc6613.txt- A packet originated by a RADIUS client to a RADIUS server. For
../data/rfc/rfc6613.txt: example, Access-Request, Accounting-Request, CoA-Request, or
../data/rfc/rfc6613.txt- Disconnect-Request.
../data/rfc/rfc6613.txt-
../data/rfc/rfc6613.txt- RADIUS response packet
../data/rfc/rfc6613.txt- A packet sent by a RADIUS server to a RADIUS client, in response
../data/rfc/rfc6613.txt- to a RADIUS request packet. For example, Access-Accept, Access-
../data/rfc/rfc6613.txt: Reject, Access-Challenge, Accounting-Response, or CoA-ACK.
../data/rfc/rfc6613.txt-
../data/rfc/rfc6613.txt- RADIUS/UDP
../data/rfc/rfc6613.txt- RADIUS over UDP, as defined in [RFC2865].
../data/rfc/rfc6613.txt-
../data/rfc/rfc6613.txt- RADIUS/TCP
--
../data/rfc/rfc6613.txt- is also noted in [RFC3539], Section 2.4.
../data/rfc/rfc6613.txt-
../data/rfc/rfc6613.txt- An additional limit is the requirement to send a Status-Server packet
../data/rfc/rfc6613.txt- over the same TCP connection as is used for normal requests. As
../data/rfc/rfc6613.txt- noted in [RFC5997], the response to a Status-Server packet is either
../data/rfc/rfc6613.txt: an Access-Accept or an Accounting-Response. If all IDs were
../data/rfc/rfc6613.txt- allocated to normal requests, then there would be no free ID to use
../data/rfc/rfc6613.txt- for the Status-Server packet, and it could not be sent over the
../data/rfc/rfc6613.txt- connection.
../data/rfc/rfc6613.txt-
../data/rfc/rfc6613.txt- Implementations SHOULD reserve ID zero (0) on each TCP connection for
--
../data/rfc/rfc6613.txt- [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
../data/rfc/rfc6613.txt- "Remote Authentication Dial In User Service (RADIUS)",
../data/rfc/rfc6613.txt- RFC 2865, June 2000.
../data/rfc/rfc6613.txt-
../data/rfc/rfc6613.txt- [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization
../data/rfc/rfc6613.txt: and Accounting (AAA) Transport Profile", RFC 3539, June
../data/rfc/rfc6613.txt- 2003.
../data/rfc/rfc6613.txt-
../data/rfc/rfc6613.txt- [RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote
../data/rfc/rfc6613.txt- Authentication Dial In User Service (RADIUS) Protocol",
../data/rfc/rfc6613.txt- RFC 5997, August 2010.
--
../data/rfc/rfc6613.txt- "Transport Layer Security (TLS) Encryption for RADIUS",
../data/rfc/rfc6613.txt- RFC 6614, May 2012.
../data/rfc/rfc6613.txt-
../data/rfc/rfc6613.txt-5.2. Informative References
../data/rfc/rfc6613.txt-
../data/rfc/rfc6613.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc6613.txt-
../data/rfc/rfc6613.txt- [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
../data/rfc/rfc6613.txt- Dial In User Service) Support For Extensible
../data/rfc/rfc6613.txt- Authentication Protocol (EAP)", RFC 3579, September
../data/rfc/rfc6613.txt- 2003.
--
../data/rfc/rfc6613.txt-
../data/rfc/rfc6613.txt-
../data/rfc/rfc6613.txt- [RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6",
../data/rfc/rfc6613.txt- RFC 4669, August 2006.
../data/rfc/rfc6613.txt-
../data/rfc/rfc6613.txt: [RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC
../data/rfc/rfc6613.txt- 4670, August 2006.
../data/rfc/rfc6613.txt-
../data/rfc/rfc6613.txt: [RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6", RFC
../data/rfc/rfc6613.txt- 4671, August 2006.
../data/rfc/rfc6613.txt-
../data/rfc/rfc6613.txt- [RFC4672] De Cnodder, S., Jonnala, N., and M. Chiba, "RADIUS
../data/rfc/rfc6613.txt- Dynamic Authorization Client MIB", RFC 4672, September
../data/rfc/rfc6613.txt- 2006.
--
../data/rfc/rfc3344.txt-
../data/rfc/rfc3344.txt- When the mobile node receives an Agent Advertisement with the 'R' bit
../data/rfc/rfc3344.txt- set, the mobile node SHOULD register through the foreign agent, even
../data/rfc/rfc3344.txt- when the mobile node might be able to acquire its own co-located
../data/rfc/rfc3344.txt- care-of address. This feature is intended to allow sites to enforce
../data/rfc/rfc3344.txt: visiting policies (such as accounting) which require exchanges of
../data/rfc/rfc3344.txt- authorization.
../data/rfc/rfc3344.txt-
../data/rfc/rfc3344.txt- If formerly reserved bits require some kind of monitoring/enforcement
../data/rfc/rfc3344.txt- at the foreign link, foreign agents implementing the new
../data/rfc/rfc3344.txt- specification for the formerly reserved bits can set the 'R' bit.
--
../data/rfc/rfc2512.txt- A. Prasad
../data/rfc/rfc2512.txt- Cisco Systems, Inc.
../data/rfc/rfc2512.txt- February 1999
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt: Accounting Information for ATM Networks
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-Status of this Memo
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt- This document specifies an Internet standards track protocol for the
../data/rfc/rfc2512.txt- Internet community, and requests discussion and suggestions for
--
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt- This memo defines a portion of the Management Information Base (MIB)
../data/rfc/rfc2512.txt- for use with network management protocols in the Internet community.
../data/rfc/rfc2512.txt- A separate memo [16] defines managed objects, in a manner independent
../data/rfc/rfc2512.txt- of the type of network, for controlling the selection, collection and
../data/rfc/rfc2512.txt: storage of accounting information into files for later retrieval via
../data/rfc/rfc2512.txt- a file transfer protocol. This memo defines a set of ATM-specific
../data/rfc/rfc2512.txt: accounting information which can be collected for connections on ATM
../data/rfc/rfc2512.txt- networks.
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-McCloghrie, et. al. Standards Track [Page 1]
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt:RFC 2512 Accounting Information for ATM Networks February 1999
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-2. The SNMP Network Management Framework
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt- The SNMP Management Framework presently consists of five major
--
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-McCloghrie, et. al. Standards Track [Page 2]
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt:RFC 2512 Accounting Information for ATM Networks February 1999
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-3. Overview
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt: In [16], the items of accounting data to be collected are specified
../data/rfc/rfc2512.txt- as a set of objects. Which objects are contained in such a set is
../data/rfc/rfc2512.txt- selectable by an administrator through the specification of one or
../data/rfc/rfc2512.txt- more (subtree, list) tuples, where the set of objects to be collected
../data/rfc/rfc2512.txt- is the union of the subsets specified by each tuple:
../data/rfc/rfc2512.txt-
--
../data/rfc/rfc2512.txt- of the string's value is set then the the subset contains the
../data/rfc/rfc2512.txt- object named by appending N as a single additional sub-
../data/rfc/rfc2512.txt- identifier to the subtree.
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt- This memo specifies such a subtree containing a set of objects
../data/rfc/rfc2512.txt: defining items of accounting information which are applicable to ATM
../data/rfc/rfc2512.txt- connections.
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt- Note that all of the objects defined here have a MAX-ACCESS clause of
../data/rfc/rfc2512.txt- not-accessible, since their purpose is not to be read/written by
../data/rfc/rfc2512.txt- SNMP, but rather, to be the syntax and semantics of the set of
../data/rfc/rfc2512.txt- information which can be represented within a single (subtree, list)
../data/rfc/rfc2512.txt- tuple.
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-4. Definitions
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt:ATM-ACCOUNTING-INFORMATION-MIB DEFINITIONS ::= BEGIN
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-IMPORTS
../data/rfc/rfc2512.txt- MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY,
../data/rfc/rfc2512.txt- mib-2, Integer32, Counter64 FROM SNMPv2-SMI
../data/rfc/rfc2512.txt- DisplayString, DateAndTime FROM SNMPv2-TC
../data/rfc/rfc2512.txt- AtmAddr FROM ATM-TC-MIB;
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt:atmAccountingInformationMIB MODULE-IDENTITY
../data/rfc/rfc2512.txt- LAST-UPDATED "9611052000Z"
../data/rfc/rfc2512.txt- ORGANIZATION "IETF AToM MIB Working Group"
../data/rfc/rfc2512.txt- CONTACT-INFO "
../data/rfc/rfc2512.txt- Keith McCloghrie
../data/rfc/rfc2512.txt- Cisco Systems, Inc.
--
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-McCloghrie, et. al. Standards Track [Page 3]
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt:RFC 2512 Accounting Information for ATM Networks February 1999
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt- DESCRIPTION
../data/rfc/rfc2512.txt: "The MIB module for identifying items of accounting
../data/rfc/rfc2512.txt- information which are applicable to ATM connections."
../data/rfc/rfc2512.txt- ::= { mib-2 59 }
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-atmAcctngMIBObjects OBJECT IDENTIFIER ::=
../data/rfc/rfc2512.txt: { atmAccountingInformationMIB 1 }
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt:-- Definitions of objects for use in specifying ATM accounting
../data/rfc/rfc2512.txt--- data to be collected
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-atmAcctngDataObjects OBJECT-IDENTITY
../data/rfc/rfc2512.txt- STATUS current
../data/rfc/rfc2512.txt- DESCRIPTION
../data/rfc/rfc2512.txt- "This identifier defines a subtree under which various
../data/rfc/rfc2512.txt- objects are defined such that a set of objects to be
../data/rfc/rfc2512.txt: collected as ATM accounting data can be specified as a
../data/rfc/rfc2512.txt- (subtree, list) tuple using this identifier as the subtree."
../data/rfc/rfc2512.txt- ::= { atmAcctngMIBObjects 1 }
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt--- Objects defined under the atmAcctngDataObjects subtree
../data/rfc/rfc2512.txt---
../data/rfc/rfc2512.txt--- In each case the semantics of the object are interpreted with
../data/rfc/rfc2512.txt:-- respect to the creation/storage of an accounting record for a
../data/rfc/rfc2512.txt--- particular connection on a particular interface.
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-atmAcctngConnectionType OBJECT-TYPE
../data/rfc/rfc2512.txt- SYNTAX INTEGER { pvc(1),
../data/rfc/rfc2512.txt- pvp(2),
--
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-McCloghrie, et. al. Standards Track [Page 4]
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt:RFC 2512 Accounting Information for ATM Networks February 1999
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt- STATUS current
../data/rfc/rfc2512.txt- DESCRIPTION
../data/rfc/rfc2512.txt- "An indication of whether the connection is point-to-point
--
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-McCloghrie, et. al. Standards Track [Page 5]
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt:RFC 2512 Accounting Information for ATM Networks February 1999
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt- SYNTAX AtmAddr
../data/rfc/rfc2512.txt- MAX-ACCESS not-accessible
../data/rfc/rfc2512.txt- STATUS current
--
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-McCloghrie, et. al. Standards Track [Page 6]
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt:RFC 2512 Accounting Information for ATM Networks February 1999
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt- onCommand(3) }
../data/rfc/rfc2512.txt- MAX-ACCESS not-accessible
../data/rfc/rfc2512.txt- STATUS current
--
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-McCloghrie, et. al. Standards Track [Page 7]
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt:RFC 2512 Accounting Information for ATM Networks February 1999
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt- STATUS current
../data/rfc/rfc2512.txt- DESCRIPTION
../data/rfc/rfc2512.txt- "The number of cells, including OAM cells, received by this
--
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-McCloghrie, et. al. Standards Track [Page 8]
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt:RFC 2512 Accounting Information for ATM Networks February 1999
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt- ::= { atmAcctngDataObjects 21 }
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-atmAcctngTransmitTrafficDescriptorParam3 OBJECT-TYPE
--
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-McCloghrie, et. al. Standards Track [Page 9]
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt:RFC 2512 Accounting Information for ATM Networks February 1999
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-atmAcctngReceiveTrafficDescriptorParam1 OBJECT-TYPE
../data/rfc/rfc2512.txt- SYNTAX INTEGER (0..2147483647)
../data/rfc/rfc2512.txt- MAX-ACCESS not-accessible
--
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-McCloghrie, et. al. Standards Track [Page 10]
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt:RFC 2512 Accounting Information for ATM Networks February 1999
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt- DESCRIPTION
../data/rfc/rfc2512.txt- "The fifth traffic descriptor parameter in the direction in
../data/rfc/rfc2512.txt- which this switch receives cells on this connection.
--
../data/rfc/rfc2512.txt- SYNTAX OCTET STRING (SIZE(2))
../data/rfc/rfc2512.txt- MAX-ACCESS not-accessible
../data/rfc/rfc2512.txt- STATUS current
../data/rfc/rfc2512.txt- DESCRIPTION
../data/rfc/rfc2512.txt- "The value of the CRC-16 checksum (as defined by ISO 3309
../data/rfc/rfc2512.txt: (HDLC) and/or ITU X.25) calculated over the accounting
../data/rfc/rfc2512.txt- record containing this object.
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt- While the mechanism for calculating/encoding the checksum
../data/rfc/rfc2512.txt: value is specific to the method of encoding the accounting
../data/rfc/rfc2512.txt: record, an accounting record containing this object is
../data/rfc/rfc2512.txt- typically generated by initializing the value of this object
../data/rfc/rfc2512.txt- to the all-zeros string ('0000'H), with the location of
../data/rfc/rfc2512.txt- these zeros being saved. After generating the record, the
../data/rfc/rfc2512.txt- checksum is calculated over the whole connection record and
../data/rfc/rfc2512.txt- then the all-zeros value is overwritten (at the saved
--
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-McCloghrie, et. al. Standards Track [Page 11]
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt:RFC 2512 Accounting Information for ATM Networks February 1999
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-END
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-5. Acknowledgements
--
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-McCloghrie, et. al. Standards Track [Page 12]
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt:RFC 2512 Accounting Information for ATM Networks February 1999
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt- [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)
../data/rfc/rfc2512.txt- for version 3 of the Simple Network Management Protocol
../data/rfc/rfc2512.txt- (SNMPv3)", RFC 2274, January 1998.
--
../data/rfc/rfc2512.txt- [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
../data/rfc/rfc2512.txt- Control Model (VACM) for the Simple Network Management Protocol
../data/rfc/rfc2512.txt- (SNMP)", RFC 2275, January 1998.
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt- [16] McCloghrie, K., Heinanen, J., Greene, W. and A. Prasad, "Managed
../data/rfc/rfc2512.txt: Objects for Controlling the Collection and Storage of Accounting
../data/rfc/rfc2512.txt- Information for Connection-Oriented Networks", RFC 2513,
../data/rfc/rfc2512.txt- February 1999.
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt- [17] Noto, M., Spiegel, E. and K. Tesink, "Definitions of Textual
../data/rfc/rfc2512.txt- Conventions and OBJECT-IDENTITIES for ATM Management", RFC 2514,
../data/rfc/rfc2512.txt- February 1999.
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-7. Security Considerations
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt: This MIB module defines data items for potential use as accounting
../data/rfc/rfc2512.txt- information. Each of these data items is only accessible through a
../data/rfc/rfc2512.txt: collected accounting file. After being collected, the accounting
../data/rfc/rfc2512.txt- data should be protected against modification or unauthorized
../data/rfc/rfc2512.txt- deletion.
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-8. IANA Considerations
../data/rfc/rfc2512.txt-
--
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-McCloghrie, et. al. Standards Track [Page 13]
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt:RFC 2512 Accounting Information for ATM Networks February 1999
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-9. Authors' Addresses
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt- Keith McCloghrie
--
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-McCloghrie, et. al. Standards Track [Page 14]
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt:RFC 2512 Accounting Information for ATM Networks February 1999
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt-10. Full Copyright Statement
../data/rfc/rfc2512.txt-
../data/rfc/rfc2512.txt- Copyright (C) The Internet Society (1999). All Rights Reserved.
--
../data/rfc/rfc4652.txt- (maximum/ minimum) bandwidth per priority of which an LSP can make
../data/rfc/rfc4652.txt- use. This information is usually used in combination with the
../data/rfc/rfc4652.txt- Unreserved Bandwidth sub-TLV that provides the amount of bandwidth
../data/rfc/rfc4652.txt- not yet reserved on a TE link.
../data/rfc/rfc4652.txt-
../data/rfc/rfc4652.txt: In the ASON context, other bandwidth accounting representations are
../data/rfc/rfc4652.txt- possible, e.g., in terms of a set of tuples <signal_type; number of
../data/rfc/rfc4652.txt- unallocated timeslots>. The latter representation may also require
../data/rfc/rfc4652.txt- definition of additional signal types (from those defined in
../data/rfc/rfc4652.txt- [RFC3946]) to represent support of contiguously concatenated signals,
../data/rfc/rfc4652.txt- i.e., STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64, 256.
../data/rfc/rfc4652.txt-
../data/rfc/rfc4652.txt- However, the method proposed in [RFC4202] is the most straightforward
../data/rfc/rfc4652.txt: without requiring any bandwidth accounting change from an LSR
../data/rfc/rfc4652.txt- perspective (in particular, when the ISCD sub-TLV information is
../data/rfc/rfc4652.txt- combined with the information provided by the Unreserved Bandwidth
../data/rfc/rfc4652.txt- sub-TLV).
../data/rfc/rfc4652.txt-
../data/rfc/rfc4652.txt-
--
../data/rfc/rfc4652.txt-
../data/rfc/rfc4652.txt- Link Attributes Representation of cross/inter-layer relationships
../data/rfc/rfc4652.txt- in link top-level link TLV (see Section 5.3.1).
../data/rfc/rfc4652.txt-
../data/rfc/rfc4652.txt- Optionally, provide for per-signal-type bandwidth
../data/rfc/rfc4652.txt: accounting (see Section 5.3.1).
../data/rfc/rfc4652.txt-
../data/rfc/rfc4652.txt- Scoping TE link advertisements to allow for retrieving
../data/rfc/rfc4652.txt- their respective local-remote TE Router_ID
../data/rfc/rfc4652.txt- relationship(s) (see Section 5.7).
../data/rfc/rfc4652.txt-
--
../data/rfc/rfc4652.txt- Link Attributes Representation of cross/inter-layer relationships
../data/rfc/rfc4652.txt- in Extended IS Reachability TLV (see Section
../data/rfc/rfc4652.txt- 5.3.1).
../data/rfc/rfc4652.txt-
../data/rfc/rfc4652.txt- Optionally, provide for per-signal-type bandwidth
../data/rfc/rfc4652.txt: accounting (see Section 5.3.1).
../data/rfc/rfc4652.txt-
../data/rfc/rfc4652.txt- Scoping Extended IS Reachability TLVs to allow for
../data/rfc/rfc4652.txt- retrieving their respective local-remote TE
../data/rfc/rfc4652.txt- Router_ID relationship(s) (see Section 5.7).
../data/rfc/rfc4652.txt-
--
../data/rfc/rfc4652.txt-
../data/rfc/rfc4652.txt- Management plane: Performs management functions for the Transport
../data/rfc/rfc4652.txt- Plane, the control plane, and the system as a whole. It also
../data/rfc/rfc4652.txt- provides coordination between all the planes. The following
../data/rfc/rfc4652.txt- management functional areas are performed in the management plane:
../data/rfc/rfc4652.txt: performance, fault, configuration, accounting, and security
../data/rfc/rfc4652.txt- management
../data/rfc/rfc4652.txt-
../data/rfc/rfc4652.txt- Management domain (see Recommendation G.805): A management domain
../data/rfc/rfc4652.txt- defines a collection of managed objects that are grouped to meet
../data/rfc/rfc4652.txt- organizational requirements according to geography, technology,
../data/rfc/rfc4652.txt- policy, or other structure, and for a number of functional areas such
../data/rfc/rfc4652.txt: as fault, configuration, accounting, performance, and security
../data/rfc/rfc4652.txt- (FCAPS), for the purpose of providing control in a consistent manner.
../data/rfc/rfc4652.txt- Management domains can be disjoint, contained, or overlapping. As
../data/rfc/rfc4652.txt- such, the resources within an administrative domain can be
../data/rfc/rfc4652.txt- distributed into several possible overlapping management domains.
../data/rfc/rfc4652.txt-
--
../data/rfc/rfc4679.txt- Information Suboptions [RFC4243]. This document describes the
../data/rfc/rfc4679.txt- subscriber line identification and characterization information and
../data/rfc/rfc4679.txt- its mapping to RADIUS VSAs by the BRAS.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- The information acquired may be used to provide authentication and
../data/rfc/rfc4679.txt: accounting functionality. It may also be collected and used for
../data/rfc/rfc4679.txt- management and troubleshooting purposes.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt-2. Terminology
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- The following sections define the usage and meaning of certain
--
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- This Attribute contains information describing the subscriber
../data/rfc/rfc4679.txt- agent circuit identifier corresponding to the logical access loop
../data/rfc/rfc4679.txt- port of the Access Node/DSLAM from which a subscriber's requests
../data/rfc/rfc4679.txt- are initiated. It MAY be present in both Access-Request and
../data/rfc/rfc4679.txt: Accounting-Request packets.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- A summary of the Agent-Circuit-Id Attribute format is shown below.
../data/rfc/rfc4679.txt- The fields are transmitted from left to right.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt-
--
../data/rfc/rfc4679.txt- string sent from the Access Node/DSLAM); Agent-Remote-Id (an
../data/rfc/rfc4679.txt- operator-defined string configured on and sent by the Access
../data/rfc/rfc4679.txt- Node/DSLAM).
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- This Attribute MAY be included in both Access-Request and
../data/rfc/rfc4679.txt: Accounting-Request packets.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- A summary of the Agent-Remote-Id Attribute format is shown below.
../data/rfc/rfc4679.txt- The fields are transmitted from left to right.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- 0 1 2 3
--
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- Description
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- This Attribute contains the actual upstream train rate of a
../data/rfc/rfc4679.txt- subscriber's synchronized DSL link. It MAY be included in both
../data/rfc/rfc4679.txt: Access-Request and Accounting-Request packets.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- A summary of the Actual-Data-Rate-Upstream Attribute format is shown
../data/rfc/rfc4679.txt- below. The fields are transmitted from left to right.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- 0 1 2 3
--
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- Description
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- This Attribute contains the actual downstream train rate of a
../data/rfc/rfc4679.txt- subscriber's synchronized DSL link. It MAY be included in both
../data/rfc/rfc4679.txt: Access-Request and Accounting-Request packets.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- A summary of the Actual-Data-Rate-Downstream Attribute format is
../data/rfc/rfc4679.txt- shown below. The fields are transmitted from left to right.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt-
--
../data/rfc/rfc4679.txt-3.3.5. Minimum-Data-Rate-Upstream
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- Description
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- This Attribute contains the subscriber's operator-configured
../data/rfc/rfc4679.txt: minimum upstream data rate. It MAY be included in Accounting-
../data/rfc/rfc4679.txt- Request packets.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- A summary of the Minimum-Data-Rate-Upstream Attribute format is shown
../data/rfc/rfc4679.txt- below. The fields are transmitted from left to right.
../data/rfc/rfc4679.txt-
--
../data/rfc/rfc4679.txt-3.3.6. Minimum-Data-Rate-Downstream
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- Description
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- This Attribute contains the subscriber's operator-configured
../data/rfc/rfc4679.txt: minimum downstream data rate. It MAY be included in Accounting-
../data/rfc/rfc4679.txt- Request packets.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- A summary of the Minimum-Data-Rate-Downstream Attribute format is
../data/rfc/rfc4679.txt- shown below. The fields are transmitted from left to right.
../data/rfc/rfc4679.txt-
--
../data/rfc/rfc4679.txt-3.3.7. Attainable-Data-Rate-Upstream
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- Description
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- This Attribute contains the subscriber's attainable upstream data
../data/rfc/rfc4679.txt: rate. It MAY be included in Accounting-Request packets.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- A summary of the Attainable-Data-Rate-Upstream Attribute format is
../data/rfc/rfc4679.txt- shown below. The fields are transmitted from left to right.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt-
--
../data/rfc/rfc4679.txt-3.3.8. Attainable-Data-Rate-Downstream
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- Description
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- This Attribute contains the subscriber's attainable downstream
../data/rfc/rfc4679.txt: data rate. It MAY be included in Accounting-Request packets.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- A summary of the Attainable-Data-Rate-Downstream Attribute format is
../data/rfc/rfc4679.txt- shown below. The fields are transmitted from left to right.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- 0 1 2 3
--
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- Description
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- This Attribute contains the subscriber's maximum upstream data
../data/rfc/rfc4679.txt- rate, as configured by the operator. It MAY be included in
../data/rfc/rfc4679.txt: Accounting-Request packets.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- A summary of the Maximum-Data-Rate-Upstream Attribute format is shown
../data/rfc/rfc4679.txt- below. The fields are transmitted from left to right.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- 0 1 2 3
--
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- Description
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- This Attribute contains the subscriber's maximum downstream data
../data/rfc/rfc4679.txt- rate, as configured by the operator. It MAY be included in
../data/rfc/rfc4679.txt: Accounting-Request packets.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt-
--
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- Description
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- This Attribute contains the subscriber's minimum upstream data
../data/rfc/rfc4679.txt- rate in low power state, as configured by the operator. It MAY be
../data/rfc/rfc4679.txt: included in Accounting-Request packets.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- A summary of the Minimum-Data-Rate-Upstream-Low-Power Attribute
../data/rfc/rfc4679.txt- format is shown below. The fields are transmitted from left to
../data/rfc/rfc4679.txt- right.
../data/rfc/rfc4679.txt-
--
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- Description
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- This Attribute contains the subscriber's minimum downstream data
../data/rfc/rfc4679.txt- rate in low power state, as configured by the operator. It MAY be
../data/rfc/rfc4679.txt: included in Accounting-Request packets.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- A summary of the Minimum-Data-Rate-Downstream-Low-Power Attribute
../data/rfc/rfc4679.txt- format is shown below. The fields are transmitted from left to
../data/rfc/rfc4679.txt- right.
../data/rfc/rfc4679.txt-
--
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- Description
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- This Attribute contains the subscriber's maximum one-way upstream
../data/rfc/rfc4679.txt- interleaving delay, as configured by the operator. It MAY be
../data/rfc/rfc4679.txt: included in Accounting-Request packets.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- A summary of the Maximum-Interleaving-Delay-Upstream Attribute format
../data/rfc/rfc4679.txt- is shown below. The fields are transmitted from left to right.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- 0 1 2 3
--
../data/rfc/rfc4679.txt-3.3.14. Actual-Interleaving-Delay-Upstream
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- Description
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- This Attribute contains the subscriber's actual one-way upstream
../data/rfc/rfc4679.txt: interleaving delay. It MAY be included in Accounting-Request
../data/rfc/rfc4679.txt- packets.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- A summary of the Actual-Interleaving-Delay-Upstream Attribute format
../data/rfc/rfc4679.txt- is shown below. The fields are transmitted from left to right.
../data/rfc/rfc4679.txt-
--
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- Description
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- This Attribute contains the subscriber's maximum one-way
../data/rfc/rfc4679.txt- downstream interleaving delay, as configured by the operator. It
../data/rfc/rfc4679.txt: MAY be included in Accounting-Request packets.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- A summary of the Maximum-Interleaving-Delay-Downstream Attribute
../data/rfc/rfc4679.txt- format is shown below. The fields are transmitted from left to
../data/rfc/rfc4679.txt- right.
../data/rfc/rfc4679.txt-
--
../data/rfc/rfc4679.txt-3.3.16. Actual-Interleaving-Delay-Downstream
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- Description
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- This Attribute contains the subscriber's actual one-way downstream
../data/rfc/rfc4679.txt: interleaving delay. It MAY be included in Accounting-Request
../data/rfc/rfc4679.txt- packets.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- A summary of the Actual-Interleaving-Delay-Downstream Attribute
../data/rfc/rfc4679.txt- format is shown below. The fields are transmitted from left to
../data/rfc/rfc4679.txt- right.
--
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- Description
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- This Attribute describes the encapsulation(s) used by the
../data/rfc/rfc4679.txt- subscriber on the DSL access loop. It MAY be present in both
../data/rfc/rfc4679.txt: Access-Request and Accounting-Request packets.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- A summary of the Access-Loop-Encapsulation Attribute format is shown
../data/rfc/rfc4679.txt- below. The fields are transmitted from left to right.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- 0 1 2 3
--
../data/rfc/rfc4679.txt- Description
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- The presence of this Attribute indicates that the IWF has been
../data/rfc/rfc4679.txt- performed with respect to the subscriber's session; note that no
../data/rfc/rfc4679.txt- data field is necessary. It MAY be included in both Access-
../data/rfc/rfc4679.txt: Request and Accounting-Request packets.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- A summary of the IWF-Session Attribute format is shown below. The
../data/rfc/rfc4679.txt- fields are transmitted from left to right.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- 0 1
--
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
../data/rfc/rfc4679.txt- "Remote Authentication Dial In User Service (RADIUS)",
../data/rfc/rfc4679.txt- RFC 2865, June 2000.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt-6.2. Informative References
../data/rfc/rfc4679.txt-
../data/rfc/rfc4679.txt- [IANA] Internet Assigned Numbers Authority, "PRIVATE ENTERPRISE
../data/rfc/rfc4679.txt- NUMBERS", January 2006,
--
../data/rfc/rfc762.txt- 1 1 Reserved
../data/rfc/rfc762.txt- 2-71 2-107 AHHP Regular Messages [1,3]
../data/rfc/rfc762.txt- 72-151 110-227 Reserved
../data/rfc/rfc762.txt- 152 230 PARC Universal Protocol
../data/rfc/rfc762.txt- 153 231 TIP Status Reporting
../data/rfc/rfc762.txt: 154 232 TIP Accounting
../data/rfc/rfc762.txt- 155-158 233-236 Internet Protocol [44]
../data/rfc/rfc762.txt- 159-191 237-277 Measurements [28]
../data/rfc/rfc762.txt- 192-195 300-303 Message Switching Protocol [4,5]
../data/rfc/rfc762.txt- 196-255 304-377 Experimental Protocols
../data/rfc/rfc762.txt- 224-255 340-377 NVP [1,39]
--
../data/rfc/rfc1095.txt- functional areas to meet specific management needs. This has proved
../data/rfc/rfc1095.txt- to be a helpful way of partitioning the network management problem
../data/rfc/rfc1095.txt- from an application point of view. These facilities have come to be
../data/rfc/rfc1095.txt- known as the Specific Management Functional Areas (SMFAs): fault
../data/rfc/rfc1095.txt- management, configuration management, performance management,
../data/rfc/rfc1095.txt: accounting management, and security management. Fault management
../data/rfc/rfc1095.txt- provides the ability to detect, isolate, and correct network
../data/rfc/rfc1095.txt- problems. Configuration management enables network managers to
../data/rfc/rfc1095.txt- change the configuration of remote network elements. Performance
../data/rfc/rfc1095.txt-
../data/rfc/rfc1095.txt-
--
../data/rfc/rfc1095.txt-
../data/rfc/rfc1095.txt-RFC 1095 CMOT April 1989
../data/rfc/rfc1095.txt-
../data/rfc/rfc1095.txt-
../data/rfc/rfc1095.txt- management provides the facilities to monitor and evaluate the
../data/rfc/rfc1095.txt: performance of the network. Accounting management makes it possible
../data/rfc/rfc1095.txt- to charge users for network resources used and to limit the use of
../data/rfc/rfc1095.txt- those resources. Finally, security management is concerned with
../data/rfc/rfc1095.txt- managing access control, authentication, encryption, key management,
../data/rfc/rfc1095.txt- and so on.
../data/rfc/rfc1095.txt-
--
../data/rfc/rfc1095.txt-
../data/rfc/rfc1095.txt-4.1.2. The Functional Model
../data/rfc/rfc1095.txt-
../data/rfc/rfc1095.txt- The CMOT architecture provides the foundation for carrying out
../data/rfc/rfc1095.txt- management in the five functional areas (fault, configuration,
../data/rfc/rfc1095.txt: performance, accounting, and security), but does not address
../data/rfc/rfc1095.txt- specifically how any of these types of management are accomplished.
../data/rfc/rfc1095.txt- It is anticipated that most functional requirements can be satisfied
../data/rfc/rfc1095.txt- by CMIS. The greatest impact of the functional requirements in the
../data/rfc/rfc1095.txt- various areas will likely be on the definition of managed objects.
../data/rfc/rfc1095.txt-
--
../data/rfc/rfc2059.txt-Network Working Group C. Rigney
../data/rfc/rfc2059.txt-Request for Comments: 2059 Livingston
../data/rfc/rfc2059.txt-Category: Informational January 1997
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: RADIUS Accounting
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Status of this Memo
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- This memo provides information for the Internet community. This memo
../data/rfc/rfc2059.txt- does not specify an Internet standard of any kind. Distribution of
../data/rfc/rfc2059.txt- this memo is unlimited.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Abstract
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: This document describes a protocol for carrying accounting
../data/rfc/rfc2059.txt: information between a Network Access Server and a shared Accounting
../data/rfc/rfc2059.txt- Server.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Table of Contents
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- 1. Introduction .......................................... 2
../data/rfc/rfc2059.txt- 1.1 Specification of Requirements ................... 3
../data/rfc/rfc2059.txt- 1.2 Terminology ..................................... 3
../data/rfc/rfc2059.txt- 2. Operation ............................................. 3
../data/rfc/rfc2059.txt- 3. Packet Format ......................................... 4
../data/rfc/rfc2059.txt- 4. Packet Types .......................................... 6
../data/rfc/rfc2059.txt: 4.1 Accounting-Request .............................. 7
../data/rfc/rfc2059.txt: 4.2 Accounting-Response ............................. 8
../data/rfc/rfc2059.txt- 5. Attributes ............................................ 9
../data/rfc/rfc2059.txt- 5.1 Acct-Status-Type ................................ 11
../data/rfc/rfc2059.txt- 5.2 Acct-Delay-Time ................................. 12
../data/rfc/rfc2059.txt- 5.3 Acct-Input-Octets ............................... 13
../data/rfc/rfc2059.txt- 5.4 Acct-Output-Octets .............................. 13
--
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Rigney Informational [Page 1]
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt:RFC 2059 RADIUS Accounting January 1997
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-1. Introduction
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Managing dispersed serial line and modem pools for large numbers of
../data/rfc/rfc2059.txt- users can create the need for significant administrative support.
../data/rfc/rfc2059.txt- Since modem pools are by definition a link to the outside world, they
../data/rfc/rfc2059.txt: require careful attention to security, authorization and accounting.
../data/rfc/rfc2059.txt- This can be best achieved by managing a single "database" of users,
../data/rfc/rfc2059.txt- which allows for authentication (verifying user name and password) as
../data/rfc/rfc2059.txt- well as configuration information detailing the type of service to
../data/rfc/rfc2059.txt- deliver to the user (for example, SLIP, PPP, telnet, rlogin).
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- The RADIUS (Remote Authentication Dial In User Service) document [4]
../data/rfc/rfc2059.txt- specifies the RADIUS protocol used for Authentication and
../data/rfc/rfc2059.txt- Authorization. This memo extends the use of the RADIUS protocol to
../data/rfc/rfc2059.txt: cover delivery of accounting information from the Network Access
../data/rfc/rfc2059.txt: Server (NAS) to a RADIUS accounting server.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: Key features of RADIUS Accounting are:
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Client/Server Model
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- A Network Access Server (NAS) operates as a client of the
../data/rfc/rfc2059.txt: RADIUS accounting server. The client is responsible for
../data/rfc/rfc2059.txt: passing user accounting information to a designated RADIUS
../data/rfc/rfc2059.txt: accounting server.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: The RADIUS accounting server is responsible for receiving the
../data/rfc/rfc2059.txt: accounting request and returning a response to the client
../data/rfc/rfc2059.txt- indicating that it has successfully received the request.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: The RADIUS accounting server can act as a proxy client to other
../data/rfc/rfc2059.txt: kinds of accounting servers.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Network Security
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: Transactions between the client and RADIUS accounting server
../data/rfc/rfc2059.txt- are authenticated through the use of a shared secret, which is
../data/rfc/rfc2059.txt- never sent over the network.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Extensible Protocol
../data/rfc/rfc2059.txt-
--
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Rigney Informational [Page 2]
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt:RFC 2059 RADIUS Accounting January 1997
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-1.1 Specification of Requirements
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- MUST This word, or the adjective "required", means that the
--
../data/rfc/rfc2059.txt- constitutes a session, with the beginning of the session
../data/rfc/rfc2059.txt- defined as the point where service is first provided and
../data/rfc/rfc2059.txt- the end of the session defined as the point where service
../data/rfc/rfc2059.txt- is ended. A user may have multiple sessions in parallel or
../data/rfc/rfc2059.txt- series if the NAS supports that, with each session
../data/rfc/rfc2059.txt: generating a separate start and stop accounting record with
../data/rfc/rfc2059.txt- its own Acct-Session-Id.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- silently discard
../data/rfc/rfc2059.txt- This means the implementation discards the packet without
../data/rfc/rfc2059.txt- further processing. The implementation SHOULD provide the
--
../data/rfc/rfc2059.txt- the silently discarded packet, and SHOULD record the event
../data/rfc/rfc2059.txt- in a statistics counter.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-2. Operation
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: When a client is configured to use RADIUS Accounting, at the start of
../data/rfc/rfc2059.txt: service delivery it will generate an Accounting Start packet
../data/rfc/rfc2059.txt- describing the type of service being delivered and the user it is
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Rigney Informational [Page 3]
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt:RFC 2059 RADIUS Accounting January 1997
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: being delivered to, and will send that to the RADIUS Accounting
../data/rfc/rfc2059.txt- server, which will send back an acknowledgement that the packet has
../data/rfc/rfc2059.txt- been received. At the end of service delivery the client will
../data/rfc/rfc2059.txt: generate an Accounting Stop packet describing the type of service
../data/rfc/rfc2059.txt- that was delivered and optionally statistics such as elapsed time,
../data/rfc/rfc2059.txt- input and output octets, or input and output packets. It will send
../data/rfc/rfc2059.txt: that to the RADIUS Accounting server, which will send back an
../data/rfc/rfc2059.txt- acknowledgement that the packet has been received.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: The Accounting-Request (whether for Start or Stop) is submitted to
../data/rfc/rfc2059.txt: the RADIUS accounting server via the network. It is recommended that
../data/rfc/rfc2059.txt: the client continue attempting to send the Accounting-Request packet
../data/rfc/rfc2059.txt- until it receives an acknowledgement, using some form of backoff. If
../data/rfc/rfc2059.txt- no response is returned within a length of time, the request is re-
../data/rfc/rfc2059.txt- sent a number of times. The client can also forward requests to an
../data/rfc/rfc2059.txt- alternate server or servers in the event that the primary server is
../data/rfc/rfc2059.txt- down or unreachable. An alternate server can be used either after a
../data/rfc/rfc2059.txt- number of tries to the primary server fail, or in a round-robin
../data/rfc/rfc2059.txt- fashion. Retry and fallback algorithms are the topic of current
../data/rfc/rfc2059.txt- research and are not specified in detail in this document.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: The RADIUS accounting server MAY make requests of other servers in
../data/rfc/rfc2059.txt- order to satisfy the request, in which case it acts as a client.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: If the RADIUS accounting server is unable to successfully record the
../data/rfc/rfc2059.txt: accounting packet it MUST NOT send an Accounting-Response
../data/rfc/rfc2059.txt- acknowledgment to the client.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-3. Packet Format
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: Exactly one RADIUS Accounting packet is encapsulated in the UDP Data
../data/rfc/rfc2059.txt- field [1], where the UDP Destination Port field indicates 1813
../data/rfc/rfc2059.txt- (decimal).
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- When a reply is generated, the source and destination ports are
../data/rfc/rfc2059.txt- reversed.
--
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Rigney Informational [Page 4]
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt:RFC 2059 RADIUS Accounting January 1997
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- A summary of the RADIUS data format is shown below. The fields are
../data/rfc/rfc2059.txt- transmitted from left to right.
../data/rfc/rfc2059.txt-
--
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- The Code field is one octet, and identifies the type of RADIUS
../data/rfc/rfc2059.txt- packet. When a packet is received with an invalid Code field, it is
../data/rfc/rfc2059.txt- silently discarded.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: RADIUS Accounting Codes (decimal) are assigned as follows:
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: 4 Accounting-Request
../data/rfc/rfc2059.txt: 5 Accounting-Response
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Identifier
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- The Identifier field is one octet, and aids in matching requests and
--
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Authenticator
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- The Authenticator field is sixteen (16) octets. The most significant
../data/rfc/rfc2059.txt- octet is transmitted first. This value is used to authenticate the
../data/rfc/rfc2059.txt: messages between the client and RADIUS accounting server.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Rigney Informational [Page 5]
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt:RFC 2059 RADIUS Accounting January 1997
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Request Authenticator
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: In Accounting-Request Packets, the Authenticator value is a 16
../data/rfc/rfc2059.txt- octet MD5 [3] checksum, called the Request Authenticator.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: The NAS and RADIUS accounting server share a secret. The Request
../data/rfc/rfc2059.txt: Authenticator field in Accounting-Request packets contains a one-
../data/rfc/rfc2059.txt- way MD5 hash calculated over a stream of octets consisting of the
../data/rfc/rfc2059.txt- Code + Identifier + Length + 16 zero octets + request attributes +
../data/rfc/rfc2059.txt- shared secret (where + indicates concatenation). The 16 octet MD5
../data/rfc/rfc2059.txt- hash value is stored in the Authenticator field of the
../data/rfc/rfc2059.txt: Accounting-Request packet.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: Note that the Request Authenticator of an Accounting-Request can
../data/rfc/rfc2059.txt- not be done the same way as the Request Authenticator of a RADIUS
../data/rfc/rfc2059.txt- Access-Request, because there is no User-Password attribute in an
../data/rfc/rfc2059.txt: Accounting-Request.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Response Authenticator
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: The Authenticator field in an Accounting-Response packet is called
../data/rfc/rfc2059.txt- the Response Authenticator, and contains a one-way MD5 hash
../data/rfc/rfc2059.txt: calculated over a stream of octets consisting of the Accounting-
../data/rfc/rfc2059.txt- Response Code, Identifier, Length, the Request Authenticator field
../data/rfc/rfc2059.txt: from the Accounting-Request packet being replied to, and the response
../data/rfc/rfc2059.txt- attributes if any, followed by the shared secret. The resulting 16
../data/rfc/rfc2059.txt- octet MD5 hash value is stored in the Authenticator field of the
../data/rfc/rfc2059.txt: Accounting-Response packet.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Attributes
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Attributes may have multiple instances, in such a case the order of
../data/rfc/rfc2059.txt- attributes of the same type SHOULD be preserved. The order of
--
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Rigney Informational [Page 6]
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt:RFC 2059 RADIUS Accounting January 1997
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt:4.1. Accounting-Request
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Description
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: Accounting-Request packets are sent from a client (typically a
../data/rfc/rfc2059.txt: Network Access Server or its proxy) to a RADIUS accounting server,
../data/rfc/rfc2059.txt: and convey information used to provide accounting for a service
../data/rfc/rfc2059.txt- provided to a user. The client transmits a RADIUS packet with the
../data/rfc/rfc2059.txt: Code field set to 4 (Accounting-Request).
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: Upon receipt of an Accounting-Request, the server MUST transmit an
../data/rfc/rfc2059.txt: Accounting-Response reply if it successfully records the
../data/rfc/rfc2059.txt: accounting packet, and MUST NOT transmit any reply if it fails to
../data/rfc/rfc2059.txt: record the accounting packet.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Any attribute valid in a RADIUS Access-Request or Access-Accept
../data/rfc/rfc2059.txt: packet is valid in a RADIUS Accounting-Request packet, except that
../data/rfc/rfc2059.txt: the following attributes MUST NOT be present in an Accounting-
../data/rfc/rfc2059.txt- Request: User-Password, CHAP-Password, Reply-Message, State.
../data/rfc/rfc2059.txt- Either NAS-IP-Address or NAS-Identifier MUST be present in a
../data/rfc/rfc2059.txt: RADIUS Accounting-Request. It SHOULD contain a NAS-Port or NAS-
../data/rfc/rfc2059.txt- Port-Type attribute or both unless the service does not involve a
../data/rfc/rfc2059.txt- port or the NAS does not distinguish among its ports.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: A summary of the Accounting-Request packet format is shown below.
../data/rfc/rfc2059.txt- The fields are transmitted from left to right.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- 0 1 2 3
../data/rfc/rfc2059.txt- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
../data/rfc/rfc2059.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--
../data/rfc/rfc2059.txt- | Attributes ...
../data/rfc/rfc2059.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Code
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: 4 for Accounting-Request.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Identifier
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- The Identifier field MUST be changed whenever the content of the
../data/rfc/rfc2059.txt- Attributes field changes, and whenever a valid reply has been
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Rigney Informational [Page 7]
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt:RFC 2059 RADIUS Accounting January 1997
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- received for a previous request. For retransmissions where the
../data/rfc/rfc2059.txt- contents are identical, the Identifier MUST remain unchanged.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Note that if Acct-Delay-Time is included in the attributes of an
../data/rfc/rfc2059.txt: Accounting-Request then the Acct-Delay-Time value will be updated
../data/rfc/rfc2059.txt- when the packet is retransmitted, changing the content of the
../data/rfc/rfc2059.txt- Attributes field and requiring a new Identifier and Request
../data/rfc/rfc2059.txt- Authenticator.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Request Authenticator
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: The Request Authenticator of an Accounting-Request contains a 16-
../data/rfc/rfc2059.txt- octet MD5 hash value calculated according to the method described
../data/rfc/rfc2059.txt- in "Request Authenticator" above.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Attributes
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- The Attributes field is variable in length, and contains a list of
../data/rfc/rfc2059.txt- Attributes.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt:4.2. Accounting-Response
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Description
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: Accounting-Response packets are sent by the RADIUS accounting
../data/rfc/rfc2059.txt: server to the client to acknowledge that the Accounting-Request
../data/rfc/rfc2059.txt: has been received and recorded successfully. If the Accounting-
../data/rfc/rfc2059.txt: Request was recorded successfully then the RADIUS accounting
../data/rfc/rfc2059.txt- server MUST transmit a packet with the Code field set to 5
../data/rfc/rfc2059.txt: (Accounting-Response). On reception of an Accounting-Response by
../data/rfc/rfc2059.txt- the client, the Identifier field is matched with a pending
../data/rfc/rfc2059.txt: Accounting-Request. Invalid packets are silently discarded.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: A RADIUS Accounting-Response is not required to have any
../data/rfc/rfc2059.txt- attributes in it.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
--
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Rigney Informational [Page 8]
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt:RFC 2059 RADIUS Accounting January 1997
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: A summary of the Accounting-Response packet format is shown below.
../data/rfc/rfc2059.txt- The fields are transmitted from left to right.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- 0 1 2 3
../data/rfc/rfc2059.txt- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
../data/rfc/rfc2059.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--
../data/rfc/rfc2059.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Code
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: 5 for Accounting-Response.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Identifier
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- The Identifier field is a copy of the Identifier field of the
../data/rfc/rfc2059.txt: Accounting-Request which caused this Accounting-Response.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Response Authenticator
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: The Response Authenticator of an Accounting-Response contains a
../data/rfc/rfc2059.txt- 16-octet MD5 hash value calculated according to the method
../data/rfc/rfc2059.txt- described in "Response Authenticator" above.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Attributes
../data/rfc/rfc2059.txt-
--
../data/rfc/rfc2059.txt- zero or more Attributes.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-5. Attributes
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- RADIUS Attributes carry the specific authentication, authorization
../data/rfc/rfc2059.txt: and accounting details for the request and response.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Some attributes MAY be included more than once. The effect of this
../data/rfc/rfc2059.txt- is attribute specific, and is specified in each attribute
../data/rfc/rfc2059.txt- description.
../data/rfc/rfc2059.txt-
--
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Rigney Informational [Page 9]
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt:RFC 2059 RADIUS Accounting January 1997
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- A summary of the attribute format is shown below. The fields are
../data/rfc/rfc2059.txt- transmitted from left to right.
../data/rfc/rfc2059.txt-
--
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Length
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- The Length field is one octet, and indicates the length of this
../data/rfc/rfc2059.txt- attribute including the Type, Length and Value fields. If an
../data/rfc/rfc2059.txt: attribute is received in an Accounting-Request with an invalid
../data/rfc/rfc2059.txt- Length, the entire request should be silently discarded.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Value
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- The Value field is zero or more octets and contains information
--
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Rigney Informational [Page 10]
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt:RFC 2059 RADIUS Accounting January 1997
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- string 0-253 octets
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- address 32 bit value, most significant octet first.
--
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-5.1. Acct-Status-Type
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Description
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: This attribute indicates whether this Accounting-Request marks the
../data/rfc/rfc2059.txt- beginning of the user service (Start) or the end (Stop).
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: It MAY be used by the client to mark the start of accounting (for
../data/rfc/rfc2059.txt: example, upon booting) by specifying Accounting-On and to mark the
../data/rfc/rfc2059.txt: end of accounting (for example, just before a scheduled reboot) by
../data/rfc/rfc2059.txt: specifying Accounting-Off.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- A summary of the Acct-Status-Type attribute format is shown below.
../data/rfc/rfc2059.txt- The fields are transmitted from left to right.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- 0 1 2 3
--
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Rigney Informational [Page 11]
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt:RFC 2059 RADIUS Accounting January 1997
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Value
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- The Value field is four octets.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- 1 Start
../data/rfc/rfc2059.txt- 2 Stop
../data/rfc/rfc2059.txt: 7 Accounting-On
../data/rfc/rfc2059.txt: 8 Accounting-Off
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-5.2. Acct-Delay-Time
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Description
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- This attribute indicates how many seconds the client has been
../data/rfc/rfc2059.txt- trying to send this record for, and can be subtracted from the
../data/rfc/rfc2059.txt- time of arrival on the server to find the approximate time of the
../data/rfc/rfc2059.txt: event generating this Accounting-Request. (Network transit time
../data/rfc/rfc2059.txt- is ignored.)
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Note that changing the Acct-Delay-Time causes the Identifier to
../data/rfc/rfc2059.txt- change; see the discussion under Identifier above.
../data/rfc/rfc2059.txt-
--
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Rigney Informational [Page 12]
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt:RFC 2059 RADIUS Accounting January 1997
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-5.3. Acct-Input-Octets
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Description
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- This attribute indicates how many octets have been received from
../data/rfc/rfc2059.txt- the port over the course of this service being provided, and can
../data/rfc/rfc2059.txt: only be present in Accounting-Request records where the Acct-
../data/rfc/rfc2059.txt- Status-Type is set to Stop.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- A summary of the Acct-Input-Octets attribute format is shown below.
../data/rfc/rfc2059.txt- The fields are transmitted from left to right.
../data/rfc/rfc2059.txt-
--
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Description
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- This attribute indicates how many octets have been sent to the
../data/rfc/rfc2059.txt- port in the course of delivering this service, and can only be
../data/rfc/rfc2059.txt: present in Accounting-Request records where the Acct-Status-Type
../data/rfc/rfc2059.txt- is set to Stop.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
--
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Rigney Informational [Page 13]
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt:RFC 2059 RADIUS Accounting January 1997
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- A summary of the Acct-Output-Octets attribute format is shown below.
../data/rfc/rfc2059.txt- The fields are transmitted from left to right.
../data/rfc/rfc2059.txt-
--
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-5.5. Acct-Session-Id
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Description
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: This attribute is a unique Accounting ID to make it easy to match
../data/rfc/rfc2059.txt- start and stop records in a log file. The start and stop records
../data/rfc/rfc2059.txt- for a given session MUST have the same Acct-Session-Id. It is
../data/rfc/rfc2059.txt- strongly recommended that the Acct-Session-Id be a printable ASCII
../data/rfc/rfc2059.txt- string.
../data/rfc/rfc2059.txt-
--
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Rigney Informational [Page 14]
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt:RFC 2059 RADIUS Accounting January 1997
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- A summary of the Acct-Session-Id attribute format is shown below.
../data/rfc/rfc2059.txt- The fields are transmitted from left to right.
../data/rfc/rfc2059.txt-
--
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-5.6. Acct-Authentic
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Description
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: This attribute MAY be included in an Accounting-Request to
../data/rfc/rfc2059.txt- indicate how the user was authenticated, whether by RADIUS, the
../data/rfc/rfc2059.txt- NAS itself, or another remote authentication protocol. Users who
../data/rfc/rfc2059.txt- are delivered service without being authenticated SHOULD NOT
../data/rfc/rfc2059.txt: generate Accounting records.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- A summary of the Acct-Authentic attribute format is shown below. The
../data/rfc/rfc2059.txt- fields are transmitted from left to right.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- 0 1 2 3
--
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Rigney Informational [Page 15]
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt:RFC 2059 RADIUS Accounting January 1997
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Length
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- 6
--
../data/rfc/rfc2059.txt-5.7. Acct-Session-Time
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Description
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- This attribute indicates how many seconds the user has received
../data/rfc/rfc2059.txt: service for, and can only be present in Accounting-Request records
../data/rfc/rfc2059.txt- where the Acct-Status-Type is set to Stop.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- A summary of the Acct-Session-Time attribute format is shown below.
../data/rfc/rfc2059.txt- The fields are transmitted from left to right.
../data/rfc/rfc2059.txt-
--
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Rigney Informational [Page 16]
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt:RFC 2059 RADIUS Accounting January 1997
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-5.8. Acct-Input-Packets
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Description
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- This attribute indicates how many packets have been received from
../data/rfc/rfc2059.txt- the port over the course of this service being provided to a
../data/rfc/rfc2059.txt: Framed User, and can only be present in Accounting-Request records
../data/rfc/rfc2059.txt- where the Acct-Status-Type is set to Stop.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- A summary of the Acct-Input-packets attribute format is shown below.
../data/rfc/rfc2059.txt- The fields are transmitted from left to right.
../data/rfc/rfc2059.txt-
--
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Description
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- This attribute indicates how many packets have been sent to the
../data/rfc/rfc2059.txt- port in the course of delivering this service to a Framed User,
../data/rfc/rfc2059.txt: and can only be present in Accounting-Request records where the
../data/rfc/rfc2059.txt- Acct-Status-Type is set to Stop.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
--
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Rigney Informational [Page 17]
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt:RFC 2059 RADIUS Accounting January 1997
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- A summary of the Acct-Output-Packets attribute format is shown below.
../data/rfc/rfc2059.txt- The fields are transmitted from left to right.
../data/rfc/rfc2059.txt-
--
../data/rfc/rfc2059.txt-5.10. Acct-Terminate-Cause
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Description
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- This attribute indicates how the session was terminated, and can
../data/rfc/rfc2059.txt: only be present in Accounting-Request records where the Acct-
../data/rfc/rfc2059.txt- Status-Type is set to Stop.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- A summary of the Acct-Terminate-Cause attribute format is shown
../data/rfc/rfc2059.txt- below. The fields are transmitted from left to right.
../data/rfc/rfc2059.txt-
--
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Rigney Informational [Page 18]
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt:RFC 2059 RADIUS Accounting January 1997
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Length
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- 6
--
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Rigney Informational [Page 19]
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt:RFC 2059 RADIUS Accounting January 1997
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Port Error NAS detected an error on the port which
../data/rfc/rfc2059.txt- required ending the session.
../data/rfc/rfc2059.txt-
--
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-5.11. Acct-Multi-Session-Id
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Description
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: This attribute is a unique Accounting ID to make it easy to link
../data/rfc/rfc2059.txt- together multiple related sessions in a log file. Each session
../data/rfc/rfc2059.txt- linked together would have a unique Acct-Session-Id but the same
../data/rfc/rfc2059.txt- Acct-Multi-Session-Id. It is strongly recommended that the Acct-
../data/rfc/rfc2059.txt- Multi-Session-Id be a printable ASCII string.
../data/rfc/rfc2059.txt-
--
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Rigney Informational [Page 20]
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt:RFC 2059 RADIUS Accounting January 1997
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- A summary of the Acct-Session-Id attribute format is shown below.
../data/rfc/rfc2059.txt- The fields are transmitted from left to right.
../data/rfc/rfc2059.txt-
--
../data/rfc/rfc2059.txt-5.12. Acct-Link-Count
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Description
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- This attribute gives the count of links which are known to have
../data/rfc/rfc2059.txt: been in a given multilink session at the time the accounting
../data/rfc/rfc2059.txt- record is generated. The NAS MAY include the Acct-Link-Count
../data/rfc/rfc2059.txt: attribute in any Accounting-Request which might have multiple
../data/rfc/rfc2059.txt- links.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- A summary of the Acct-Link-Count attribute format is show below. The
../data/rfc/rfc2059.txt- fields are transmitted from left to right.
../data/rfc/rfc2059.txt-
--
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Rigney Informational [Page 21]
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt:RFC 2059 RADIUS Accounting January 1997
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Length
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- 6
--
../data/rfc/rfc2059.txt- Value
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- The Value field is four octets, and contains the number of links
../data/rfc/rfc2059.txt- seen so far in this Multilink Session.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: It may be used to make it easier for an accounting server to know
../data/rfc/rfc2059.txt- when it has all the records for a given Multilink session. When
../data/rfc/rfc2059.txt: the number of Accounting-Requests received with Acct-Status-Type =
../data/rfc/rfc2059.txt- Stop and the same Acct-Multi-Session-Id and unique Acct-Session-
../data/rfc/rfc2059.txt- Id's equals the largest value of Acct-Link-Count seen in those
../data/rfc/rfc2059.txt: Accounting-Requests, all Stop Accounting-Requests for that
../data/rfc/rfc2059.txt- Multilink Session have been received.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: An example showing 8 Accounting-Requests should make things
../data/rfc/rfc2059.txt- clearer. For clarity only the relevant attributes are shown, but
../data/rfc/rfc2059.txt: additional attributes containing accounting information will also
../data/rfc/rfc2059.txt: be present in the Accounting-Request.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Multi-Session-Id Session-Id Status-Type Link-Count
../data/rfc/rfc2059.txt- "10" "10" Start 1
../data/rfc/rfc2059.txt- "10" "11" Start 2
../data/rfc/rfc2059.txt- "10" "11" Stop 2
--
../data/rfc/rfc2059.txt- "10" "10" Stop 4
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-5.13. Table of Attributes
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- The following table provides a guide to which attributes may be found
../data/rfc/rfc2059.txt: in Accounting-Request packets. No attributes should be found in
../data/rfc/rfc2059.txt: Accounting-Response packets except Proxy-State and possibly Vendor-
../data/rfc/rfc2059.txt- Specific.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- # Attribute
../data/rfc/rfc2059.txt- 0-1 User-Name
--
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Rigney Informational [Page 22]
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt:RFC 2059 RADIUS Accounting January 1997
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- 0-1 Framed-IP-Address
../data/rfc/rfc2059.txt- 0-1 Framed-IP-Netmask
../data/rfc/rfc2059.txt- 0-1 Framed-Routing
--
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Rigney Informational [Page 23]
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt:RFC 2059 RADIUS Accounting January 1997
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: [4] An Accounting-Request MUST contain either a NAS-IP-Address or a
../data/rfc/rfc2059.txt- NAS-Identifier, and it is permitted (but not recommended) for it to
../data/rfc/rfc2059.txt- contain both.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- The following table defines the above table entries.
../data/rfc/rfc2059.txt-
--
../data/rfc/rfc2059.txt- 1 Exactly one instance of this attribute MUST be present.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Security Considerations
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- Security issues are briefly discussed in sections concerning the
../data/rfc/rfc2059.txt: authenticator included in accounting requests and responses, using a
../data/rfc/rfc2059.txt- shared secret which is never sent over the network.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-References
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- [1] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
--
../data/rfc/rfc2059.txt- Authentication Dial In User Service (RADIUS)", RFC 2058,
../data/rfc/rfc2059.txt- January 1997.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Acknowledgments
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt: RADIUS and RADIUS Accounting were originally developed by Livingston
../data/rfc/rfc2059.txt- Enterprises for their PortMaster series of Network Access Servers.
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
--
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Rigney Informational [Page 24]
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt:RFC 2059 RADIUS Accounting January 1997
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt-Chair's Address
../data/rfc/rfc2059.txt-
../data/rfc/rfc2059.txt- The RADIUS working group can be contacted via the current chair:
--
../data/rfc/rfc200.txt- (May NWG Meeting)
../data/rfc/rfc200.txt-White Typographical Error in RFC 107 28 April 1971 6708 132
../data/rfc/rfc200.txt-Sundberg File Transfer and Recovery 27 April 1971 6710 133
../data/rfc/rfc200.txt-Vezza Network Graphics Meeting 29 April 1971 6711 134
../data/rfc/rfc200.txt-Hathaway Response to NWG/RFC 110 29 April 1971 6712 135
../data/rfc/rfc200.txt:Kahn Host Accounting and 29 April 1971 6713 136
../data/rfc/rfc200.txt- Administrative Procedures
../data/rfc/rfc200.txt-O'Sullivan TELNET Protocol -- 30 April 1971 6714 137
../data/rfc/rfc200.txt- A Proposed Document
../data/rfc/rfc200.txt-O'Sullivan TELNET Protocol -- 8 May 1971 6783 137
../data/rfc/rfc200.txt- A Proposed Document (rev.) rev
--
../data/rfc/rfc1012.txt- MIT-Project MAC, 29 April 1971.
../data/rfc/rfc1012.txt-
../data/rfc/rfc1012.txt- 135 - Hathaway, Wayne, "Response to NWG/RFC 110", RFC 135 (NIC 6712),
../data/rfc/rfc1012.txt- Ames Research Center, 29 April 1971.
../data/rfc/rfc1012.txt-
../data/rfc/rfc1012.txt: 136 - Kahn, Robert, "Host Accounting and Administrative Procedures",
../data/rfc/rfc1012.txt- RFC 136 (NIC 6713), BBN, 29 April 1971.
../data/rfc/rfc1012.txt-
../data/rfc/rfc1012.txt- 137 - O'Sullivan, Thomas C., "Telnet Protocol - A Proposed Document",
../data/rfc/rfc1012.txt- RFC 137 (NIC 6714), Raytheon, 30 April 1971, revised,
../data/rfc/rfc1012.txt- 8 May 1971.
--
../data/rfc/rfc5210.txt- use of spoofed source addresses.
../data/rfc/rfc5210.txt-
../data/rfc/rfc5210.txt- o Being able to assume that all packet source addresses are correct
../data/rfc/rfc5210.txt- would allow traceback to be accomplished accurately and with
../data/rfc/rfc5210.txt- confidence. This would benefit network diagnosis, management,
../data/rfc/rfc5210.txt: accounting, and applications.
../data/rfc/rfc5210.txt-
../data/rfc/rfc5210.txt- As part of the effort in developing a Source Address Validation
../data/rfc/rfc5210.txt- Architecture (SAVA), we implemented a SAVA prototype and deployed the
../data/rfc/rfc5210.txt- prototype in 12 ASes in an operational network as part of China Next
../data/rfc/rfc5210.txt- Generation Internet (CNGI) Project [Wu07]. We conducted evaluation
--
../data/rfc/rfc5470.txt- 13.1. Normative References .....................................30
../data/rfc/rfc5470.txt- 13.2. Informative References ...................................30
../data/rfc/rfc5470.txt-
../data/rfc/rfc5470.txt-1. Introduction
../data/rfc/rfc5470.txt-
../data/rfc/rfc5470.txt: There are several applications, e.g., usage-based accounting, traffic
../data/rfc/rfc5470.txt- profiling, traffic engineering, attack/intrusion detection, quality-
../data/rfc/rfc5470.txt- of-service (QoS) monitoring, that require Flow-based IP traffic
../data/rfc/rfc5470.txt- measurements. It is therefore important to have a standard way of
../data/rfc/rfc5470.txt- exporting information related to IP Flows. This document defines an
../data/rfc/rfc5470.txt- architecture for IP traffic Flow monitoring, measuring, and
--
../data/rfc/rfc5470.txt-
../data/rfc/rfc5470.txt-7. IPFIX Protocol Details
../data/rfc/rfc5470.txt-
../data/rfc/rfc5470.txt- When the IPFIX Working Group was chartered, there were existing
../data/rfc/rfc5470.txt- common practices in the area of Flow export, for example, NetFlow,
../data/rfc/rfc5470.txt: CRANE (Common Reliable Accounting for Network Element), LFAP (Light-
../data/rfc/rfc5470.txt- weight Flow Admission Protocol), RTFM (Real-time Traffic Flow
../data/rfc/rfc5470.txt- Measurement), etc. IPFIX's charter required the Working Group to
../data/rfc/rfc5470.txt- consider those existing practices, and select the one that was the
../data/rfc/rfc5470.txt- closest fit to the IPFIX requirements in RFC 3917 [1]. Additions or
../data/rfc/rfc5470.txt- modifications would then be made to the selected protocol to fit it
--
../data/rfc/rfc5470.txt- can make a clear interpretation of the received Flow Records.
../data/rfc/rfc5470.txt-
../data/rfc/rfc5470.txt-10. Security Considerations
../data/rfc/rfc5470.txt-
../data/rfc/rfc5470.txt- Flow information can be used for various purposes, such as usage-
../data/rfc/rfc5470.txt: based accounting, traffic profiling, traffic engineering, and
../data/rfc/rfc5470.txt- intrusion detection. The security requirements may differ
../data/rfc/rfc5470.txt- significantly for such applications. To be able to satisfy the
../data/rfc/rfc5470.txt- security needs of various IPFIX users, an IPFIX system must provide
../data/rfc/rfc5470.txt- different levels of security protection.
../data/rfc/rfc5470.txt-
--
../data/rfc/rfc7846.txt- 5.2. Management Considerations .................................40
../data/rfc/rfc7846.txt- 5.2.1. Interoperability ...................................40
../data/rfc/rfc7846.txt- 5.2.2. Management Information .............................40
../data/rfc/rfc7846.txt- 5.2.3. Fault Management ...................................41
../data/rfc/rfc7846.txt- 5.2.4. Configuration Management ...........................41
../data/rfc/rfc7846.txt: 5.2.5. Accounting Management ..............................41
../data/rfc/rfc7846.txt- 5.2.6. Performance Management .............................41
../data/rfc/rfc7846.txt- 5.2.7. Security Management ................................41
../data/rfc/rfc7846.txt- 6. Security Considerations ........................................42
../data/rfc/rfc7846.txt- 6.1. Authentication between Tracker and Peers ..................42
../data/rfc/rfc7846.txt- 6.2. Content Integrity Protection against Polluting
--
../data/rfc/rfc7846.txt- The management considerations for PPSTP are similar to other
../data/rfc/rfc7846.txt- solutions using HTTP for large-scale content distribution. The PPSP
../data/rfc/rfc7846.txt- tracker can be realized by geographically distributed tracker nodes
../data/rfc/rfc7846.txt- or multiple server nodes in a data center. As these nodes are akin
../data/rfc/rfc7846.txt- to WWW nodes, their configuration procedures, detection of faults,
../data/rfc/rfc7846.txt: measurement of performance, usage accounting, and security measures
../data/rfc/rfc7846.txt- can be achieved by standard solutions and facilities.
../data/rfc/rfc7846.txt-
../data/rfc/rfc7846.txt-5.2.1. Interoperability
../data/rfc/rfc7846.txt-
../data/rfc/rfc7846.txt- Interoperability refers to allowing information sharing and
--
../data/rfc/rfc7846.txt- tracker nodes or multiple server nodes in a data center, may benefit
../data/rfc/rfc7846.txt- from a standard way of replicating atomic configuration updates over
../data/rfc/rfc7846.txt- a set of server nodes. This functionality can be provided via
../data/rfc/rfc7846.txt- NETCONF [RFC6241].
../data/rfc/rfc7846.txt-
../data/rfc/rfc7846.txt:5.2.5. Accounting Management
../data/rfc/rfc7846.txt-
../data/rfc/rfc7846.txt- PPSTP implementations, primarily in content provider environments,
../data/rfc/rfc7846.txt: can benefit from accounting standardization efforts as described in
../data/rfc/rfc7846.txt: [RFC2975], which indicates that accounting management is "concerned
../data/rfc/rfc7846.txt- with the collection of resource consumption data for the purposes of
../data/rfc/rfc7846.txt- capacity and trend analysis, cost allocation, auditing, and billing".
../data/rfc/rfc7846.txt-
../data/rfc/rfc7846.txt-5.2.6. Performance Management
../data/rfc/rfc7846.txt-
--
../data/rfc/rfc7846.txt- [RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", RFC
../data/rfc/rfc7846.txt- 2790, DOI 10.17487/RFC2790, March 2000,
../data/rfc/rfc7846.txt- <http://www.rfc-editor.org/info/rfc2790>.
../data/rfc/rfc7846.txt-
../data/rfc/rfc7846.txt- [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to
../data/rfc/rfc7846.txt: Accounting Management", RFC 2975, DOI 10.17487/RFC2975,
../data/rfc/rfc7846.txt- October 2000, <http://www.rfc-editor.org/info/rfc2975>.
../data/rfc/rfc7846.txt-
../data/rfc/rfc7846.txt- [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
../data/rfc/rfc7846.txt- "Introduction and Applicability Statements for Internet-
../data/rfc/rfc7846.txt- Standard Management Framework", RFC 3410,
--
../data/rfc/rfc8014.txt- Operations, Administration, and Maintenance (OAM) [RFC6291] framework
../data/rfc/rfc8014.txt- for overlay networks can draw from prior IETF OAM work for tunnel-
../data/rfc/rfc8014.txt- based networks, specifically L2VPN OAM [RFC6136]. RFC 6136 focuses
../data/rfc/rfc8014.txt- on Fault Management and Performance Management as fundamental to
../data/rfc/rfc8014.txt- L2VPN service delivery, leaving the Configuration Management,
../data/rfc/rfc8014.txt: Accounting Management, and Security Management components of the Open
../data/rfc/rfc8014.txt: Systems Interconnection (OSI) Fault, Configuration, Accounting,
../data/rfc/rfc8014.txt- Performance, and Security (FCAPS) taxonomy [M.3400] for further
../data/rfc/rfc8014.txt- study. This section does likewise for NVO3 OAM, but those three
../data/rfc/rfc8014.txt- areas continue to be important parts of complete OAM functionality
../data/rfc/rfc8014.txt- for NVO3.
../data/rfc/rfc8014.txt-
--
../data/rfc/rfc4375.txt-
../data/rfc/rfc4375.txt-3.7. MIB
../data/rfc/rfc4375.txt-
../data/rfc/rfc4375.txt- Management Information Bases (MIBs) SHOULD be defined for mechanisms
../data/rfc/rfc4375.txt- specifically in place to support ETS. These MIBs MAY include objects
../data/rfc/rfc4375.txt: representing accounting, policy, and authorization.
../data/rfc/rfc4375.txt-
../data/rfc/rfc4375.txt-4. Issues
../data/rfc/rfc4375.txt-
../data/rfc/rfc4375.txt- This section presents issues that arise in considering solutions for
../data/rfc/rfc4375.txt- the requirements that have been defined for stub domains that support
--
../data/rfc/rfc385.txt- ------- ------- ----
../data/rfc/rfc385.txt- MAIL 350 450,451,500-506
../data/rfc/rfc385.txt- Sec Reply 256
../data/rfc/rfc385.txt-
../data/rfc/rfc385.txt- 15. An additional access control command called account (ACCT)
../data/rfc/rfc385.txt: is now defined to facilitate accounting in systems such as
../data/rfc/rfc385.txt- TENEX which require in addition to user and password, a
../data/rfc/rfc385.txt- separate account specification. The 'ACCT' command is
../data/rfc/rfc385.txt- different from the 'PASS' command in that it is not
../data/rfc/rfc385.txt- necessarily related to the 'USER' command and may arrive at
../data/rfc/rfc385.txt- any time. For example, a user may transfer different files
--
../data/rfc/rfc2748.txt- 2.2.10 Keep-Alive Timer Object (KATimer)..........................15
../data/rfc/rfc2748.txt- 2.2.11 PEP Identification Object (PEPID)..........................16
../data/rfc/rfc2748.txt- 2.2.12 Report-Type Object (Report-Type)...........................16
../data/rfc/rfc2748.txt- 2.2.13 PDP Redirect Address (PDPRedirAddr)........................16
../data/rfc/rfc2748.txt- 2.2.14 Last PDP Address (LastPDPAddr).............................17
../data/rfc/rfc2748.txt: 2.2.15 Accounting Timer Object (AcctTimer)........................17
../data/rfc/rfc2748.txt- 2.2.16 Message Integrity Object (Integrity).......................18
../data/rfc/rfc2748.txt- 2.3 Communication.................................................19
../data/rfc/rfc2748.txt- 2.4 Client Handle Usage...........................................21
../data/rfc/rfc2748.txt- 2.5 Synchronization Behavior......................................21
../data/rfc/rfc2748.txt- 3. Message Content................................................22
--
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt- decisions to the PEP to force changes in previously approved request
../data/rfc/rfc2748.txt- states. The PEP also has the capacity to report to the remote PDP
../data/rfc/rfc2748.txt- that it has successfully completed performing the PDP's decision
../data/rfc/rfc2748.txt: locally, useful for accounting and monitoring purposes. The PEP is
../data/rfc/rfc2748.txt- responsible for notifying the PDP when a request state has changed on
../data/rfc/rfc2748.txt- the PEP. Finally, the PEP is responsible for the deletion of any
../data/rfc/rfc2748.txt- state that is no longer applicable due to events at the client or
../data/rfc/rfc2748.txt- decisions issued by the server.
../data/rfc/rfc2748.txt-
--
../data/rfc/rfc2748.txt- 10 = Keep-Alive Timer
../data/rfc/rfc2748.txt- 11 = PEP Identification
../data/rfc/rfc2748.txt- 12 = Report Type
../data/rfc/rfc2748.txt- 13 = PDP Redirect Address
../data/rfc/rfc2748.txt- 14 = Last PDP Address
../data/rfc/rfc2748.txt: 15 = Accounting Timer
../data/rfc/rfc2748.txt- 16 = Message Integrity
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt- C-type: 8 bits
../data/rfc/rfc2748.txt- Values defined per C-num.
../data/rfc/rfc2748.txt-
--
../data/rfc/rfc2748.txt- +--------------+--------------+--------------+--------------+
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt- Report-Type:
../data/rfc/rfc2748.txt- 1 = Success : Decision was successful at the PEP
../data/rfc/rfc2748.txt- 2 = Failure : Decision could not be completed by PEP
../data/rfc/rfc2748.txt: 3 = Accounting: Accounting update for an installed state
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt-2.2.13 PDP Redirect Address (PDPRedirAddr)
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt- A PDP when closing a PEP session for a particular client-type may
../data/rfc/rfc2748.txt- optionally use this object to redirect the PEP to the specified PDP
--
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt- C-Type = 1, IPv4 Address (Same format as PDPRedirAddr)
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt- C-Type = 2, IPv6 Address (Same format as PDPRedirAddr)
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt:2.2.15 Accounting Timer Object (AcctTimer)
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt- Times are encoded as 2 octet integer values and are in units of
../data/rfc/rfc2748.txt- seconds. The timer value is treated as a delta.
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt- C-Num = 15,
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt: C-Type = 1, Accounting timer value
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt-
--
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt-RFC 2748 COPS January 2000
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt- Optional timer value used to determine the minimum interval between
../data/rfc/rfc2748.txt: periodic accounting type reports. It is used by the PDP to describe
../data/rfc/rfc2748.txt: to the PEP an acceptable interval between unsolicited accounting
../data/rfc/rfc2748.txt- updates via Report messages where applicable. It provides a method
../data/rfc/rfc2748.txt: for the PDP to control the amount of accounting traffic seen by the
../data/rfc/rfc2748.txt- network. The range of finite time values is 1 to 65535 seconds
../data/rfc/rfc2748.txt- represented as an unsigned two-octet integer. A value of zero means
../data/rfc/rfc2748.txt: there SHOULD be no unsolicited accounting updates.
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt- 0 1 2 3
../data/rfc/rfc2748.txt- +--------------+--------------+--------------+--------------+
../data/rfc/rfc2748.txt- | ////////////// | ACCT Timer Value |
../data/rfc/rfc2748.txt- +--------------+--------------+--------------+--------------+
--
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt-3.3 Report State (RPT) PEP -> PDP
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt- The RPT message is used by the PEP to communicate to the PDP its
../data/rfc/rfc2748.txt- success or failure in carrying out the PDP's decision, or to report
../data/rfc/rfc2748.txt: an accounting related change in state. The Report-Type specifies the
../data/rfc/rfc2748.txt- kind of report and the optional ClientSI can carry additional
../data/rfc/rfc2748.txt- information per Client-Type.
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt- For every DEC message containing a configuration context that is
../data/rfc/rfc2748.txt- received by a PEP, the PEP MUST generate a corresponding Report State
--
../data/rfc/rfc2748.txt- the same order as their corresponding Decision messages were
../data/rfc/rfc2748.txt- received. There MUST never be more than one Report State message
../data/rfc/rfc2748.txt- generated with the Solicited Message flag set per Decision.
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt- The Report State may also be used to provide periodic updates of
../data/rfc/rfc2748.txt: client specific information for accounting and state monitoring
../data/rfc/rfc2748.txt- purposes depending on the type of the client. In such cases the
../data/rfc/rfc2748.txt: accounting report type should be specified utilizing the appropriate
../data/rfc/rfc2748.txt- client specific information object.
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt- <Report State> ::== <Common Header>
../data/rfc/rfc2748.txt- <Client Handle>
../data/rfc/rfc2748.txt- <Report-Type>
--
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt- The Client-Accept message is used to positively respond to the
../data/rfc/rfc2748.txt- Client-Open message. This message will return to the PEP a timer
../data/rfc/rfc2748.txt- object indicating the maximum time interval between keep-alive
../data/rfc/rfc2748.txt- messages. Optionally, a timer specifying the minimum allowed interval
../data/rfc/rfc2748.txt: between accounting report messages may be included when applicable.
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt- <Client-Accept> ::= <Common Header>
../data/rfc/rfc2748.txt- <KA Timer>
../data/rfc/rfc2748.txt- [<ACCT Timer>]
../data/rfc/rfc2748.txt- [<Integrity>]
--
../data/rfc/rfc2748.txt- between the generation of messages by the PDP and PEP. The timer
../data/rfc/rfc2748.txt- value is determined by the PDP and is specified in seconds. A timer
../data/rfc/rfc2748.txt- value of 0 implies no secondary connection verification is necessary.
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt- The optional ACCT Timer allows the PDP to indicate to the PEP that
../data/rfc/rfc2748.txt: periodic accounting reports SHOULD NOT exceed the specified timer
../data/rfc/rfc2748.txt- interval per client handle. This allows the PDP to control the rate
../data/rfc/rfc2748.txt: at which accounting reports are sent by the PEP (when applicable).
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt-Durham, et al. Standards Track [Page 27]
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt-RFC 2748 COPS January 2000
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt: In general, accounting type Report messages are sent to the PDP when
../data/rfc/rfc2748.txt: determined appropriate by the PEP. The accounting timer merely is
../data/rfc/rfc2748.txt- used by the PDP to keep the rate of such updates in check (i.e.
../data/rfc/rfc2748.txt: Preventing the PEP from blasting the PDP with accounting reports).
../data/rfc/rfc2748.txt- Not including this object implies there are no PDP restrictions on
../data/rfc/rfc2748.txt: the rate at which accounting updates are generated.
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt- If the PEP receives a malformed Client-Accept message it MUST
../data/rfc/rfc2748.txt- generate a Client-Close message specifying the appropriate error
../data/rfc/rfc2748.txt- code.
../data/rfc/rfc2748.txt-
--
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt- In all cases, the PEP MAY notify the remote PDP of the local status
../data/rfc/rfc2748.txt- of an installed state using the report message where appropriate.
../data/rfc/rfc2748.txt- The report message is to be used to signify when billing can begin,
../data/rfc/rfc2748.txt- what actions were taken, or to produce periodic updates for
../data/rfc/rfc2748.txt: monitoring and accounting purposes depending on the client. This
../data/rfc/rfc2748.txt- message can carry client specific information when needed.
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt-4.6 Keep-Alive Operations
../data/rfc/rfc2748.txt-
../data/rfc/rfc2748.txt- The Keep-Alive message is used to validate the connection between the
--
../data/rfc/rfc1015.txt-
../data/rfc/rfc1015.txt- This is not to say that agencies may not choose to have their
../data/rfc/rfc1015.txt- individual networks operated by the IRI, or even turned over to the
../data/rfc/rfc1015.txt- IRI if they determine that to be appropriate.
../data/rfc/rfc1015.txt-
../data/rfc/rfc1015.txt: Appropriate access control, privacy, and accounting mechanisms must
../data/rfc/rfc1015.txt- be incorporated. This includes access control to data, resources,
../data/rfc/rfc1015.txt: and the networks themselves, privacy of user data, and accounting
../data/rfc/rfc1015.txt- mechanisms to support both cost allocation and cost auditing [23].
../data/rfc/rfc1015.txt-
../data/rfc/rfc1015.txt- The technical and adminstrative approach must allow (indeed
../data/rfc/rfc1015.txt- encourage) the incorporation of evolving technologies. In
../data/rfc/rfc1015.txt- particular, the network must evolve towards provision of high
--
../data/rfc/rfc3820.txt-
../data/rfc/rfc3820.txt-RFC 3820 X.509 Proxy Certificate Profile June 2004
../data/rfc/rfc3820.txt-
../data/rfc/rfc3820.txt-
../data/rfc/rfc3820.txt- [i7] Neuman, B. Clifford, "Proxy-Based Authorization and
../data/rfc/rfc3820.txt: Accounting for Distributed Systems", In Proceedings of the
../data/rfc/rfc3820.txt- 13th International Conference on Distributed Computing
../data/rfc/rfc3820.txt- Systems, pages 283-291, May 1993.
../data/rfc/rfc3820.txt-
../data/rfc/rfc3820.txt- [i8] Narten, T. and H. Alvestrand. "Guidelines for Writing an IANA
../data/rfc/rfc3820.txt- Considerations Section in RFC", RFC 2434, October 1998.
--
../data/rfc/rfc5997.txt- 1.2. Terminology ................................................4
../data/rfc/rfc5997.txt- 1.3. Requirements Language ......................................4
../data/rfc/rfc5997.txt- 2. Overview ........................................................4
../data/rfc/rfc5997.txt- 2.1. Why Access-Request is Inappropriate ........................6
../data/rfc/rfc5997.txt- 2.1.1. Recommendation against Access-Request ...............7
../data/rfc/rfc5997.txt: 2.2. Why Accounting-Request is Inappropriate ....................7
../data/rfc/rfc5997.txt: 2.2.1. Recommendation against Accounting-Request ...........7
../data/rfc/rfc5997.txt- 3. Packet Format ...................................................8
../data/rfc/rfc5997.txt- 3.1. Single Definition for Status-Server .......................10
../data/rfc/rfc5997.txt- 4. Implementation Notes ...........................................10
../data/rfc/rfc5997.txt- 4.1. Client Requirements .......................................11
../data/rfc/rfc5997.txt- 4.2. Server Requirements .......................................12
--
../data/rfc/rfc5997.txt- 4.6.1. Interaction with RADIUS Server MIB Modules .........17
../data/rfc/rfc5997.txt- 4.6.2. Interaction with RADIUS Client MIB Modules .........17
../data/rfc/rfc5997.txt- 5. Table of Attributes ............................................18
../data/rfc/rfc5997.txt- 6. Examples .......................................................19
../data/rfc/rfc5997.txt- 6.1. Minimal Query to Authentication Port ......................19
../data/rfc/rfc5997.txt: 6.2. Minimal Query to Accounting Port ..........................20
../data/rfc/rfc5997.txt- 6.3. Verbose Query and Response ................................21
../data/rfc/rfc5997.txt- 7. Security Considerations ........................................21
../data/rfc/rfc5997.txt- 8. References .....................................................23
../data/rfc/rfc5997.txt- 8.1. Normative References ......................................23
../data/rfc/rfc5997.txt- 8.2. Informative References ....................................23
--
../data/rfc/rfc5997.txt- Authenticator attribute to provide per-packet authentication and
../data/rfc/rfc5997.txt- integrity protection.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- With existing implementations of this protocol, the potential exists
../data/rfc/rfc5997.txt- for Status-Server requests to be in conflict with Access-Request or
../data/rfc/rfc5997.txt: Accounting-Request packets using the same Identifier. This
../data/rfc/rfc5997.txt- specification recommends techniques to avoid this problem.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-
--
../data/rfc/rfc5997.txt- Authenticator (in IEEE 802.1X terminology) or RADIUS client.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- "RADIUS Proxy"
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- In order to provide for the routing of RADIUS authentication and
../data/rfc/rfc5997.txt: accounting requests, a RADIUS proxy can be employed. To the NAS,
../data/rfc/rfc5997.txt- the RADIUS proxy appears to act as a RADIUS server, and to the
../data/rfc/rfc5997.txt- RADIUS server, the proxy appears to act as a RADIUS client.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- "silently discard"
../data/rfc/rfc5997.txt-
--
../data/rfc/rfc5997.txt- protection.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- RADIUS proxies or servers MUST NOT forward Status-Server packets. A
../data/rfc/rfc5997.txt- RADIUS server or proxy implementing this specification SHOULD respond
../data/rfc/rfc5997.txt- to a Status-Server packet with an Access-Accept (authentication port)
../data/rfc/rfc5997.txt: or Accounting-Response (accounting port). An Access-Challenge
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-DeKok Informational [Page 4]
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-RFC 5997 Status-Server Practices August 2010
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- response is NOT RECOMMENDED. An Access-Reject response MAY be used.
../data/rfc/rfc5997.txt- The list of attributes that are permitted in Status-Server packets,
../data/rfc/rfc5997.txt: and in Access-Accept or Accounting-Response packets responding to
../data/rfc/rfc5997.txt- Status-Server packets, is provided in Section 5. Section 6 provides
../data/rfc/rfc5997.txt- several examples.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- Since a Status-Server packet MUST NOT be forwarded by a RADIUS proxy
../data/rfc/rfc5997.txt- or server, the client is provided with an indication of the status of
--
../data/rfc/rfc5997.txt- Note that it still may be useful to configure test users for the
../data/rfc/rfc5997.txt- purpose of performing end-to-end or in-depth testing of a server
../data/rfc/rfc5997.txt- policy. While this practice is widespread, we caution administrators
../data/rfc/rfc5997.txt- to use it with care.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt:2.2. Why Accounting-Request is Inappropriate
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- A similar solution for the problem of querying server status may be
../data/rfc/rfc5997.txt: for a NAS to send specially formed Accounting-Request packets to a
../data/rfc/rfc5997.txt: RADIUS server's accounting port. The NAS can then look for a
../data/rfc/rfc5997.txt- response and use this information to determine if the server is
../data/rfc/rfc5997.txt- active or unresponsive.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- As seen above with Access-Request, the server may then conclude that
../data/rfc/rfc5997.txt- a real user has logged onto a NAS, and perform local-site actions
../data/rfc/rfc5997.txt- that are undesirable for a simple status query.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- Another consideration is that some attributes are mandatory to
../data/rfc/rfc5997.txt: include in an Accounting-Request. This requirement forces the
../data/rfc/rfc5997.txt: administrator to query an accounting server with fake values for
../data/rfc/rfc5997.txt- those attributes in a test packet. These fake values increase the
../data/rfc/rfc5997.txt- work required to perform a simple query, and they may pollute the
../data/rfc/rfc5997.txt: server's accounting database with incorrect data.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt:2.2.1. Recommendation against Accounting-Request
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- For the reasons outlined above, NAS implementors SHOULD NOT generate
../data/rfc/rfc5997.txt: Accounting-Request packets solely to see if a server is alive.
../data/rfc/rfc5997.txt: Similarly, site administrators SHOULD NOT configure accounting
../data/rfc/rfc5997.txt- policies whose sole reason for existence is to enable such queries
../data/rfc/rfc5997.txt: via Accounting-Request packets.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- Note that it still may be useful to configure test users for the
../data/rfc/rfc5997.txt- purpose of performing end-to-end or in-depth testing of a server's
../data/rfc/rfc5997.txt- policy. While this practice is widespread, we caution administrators
../data/rfc/rfc5997.txt- to use it with care.
--
../data/rfc/rfc5997.txt- using the same method as that used for the Request Authenticator
../data/rfc/rfc5997.txt- field of Access-Request packets, as given below.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- The role of the Identifier field is the same for Status-Server as for
../data/rfc/rfc5997.txt- other packets. However, as Status-Server is taking the role of
../data/rfc/rfc5997.txt: Access-Request or Accounting-Request packets, there is the potential
../data/rfc/rfc5997.txt- for Status-Server requests to be in conflict with Access-Request or
../data/rfc/rfc5997.txt: Accounting-Request packets with the same Identifier. In Section 4.2
../data/rfc/rfc5997.txt- below, we describe a method for avoiding these problems. This method
../data/rfc/rfc5997.txt- MUST be used to avoid conflicts between Status-Server and other
../data/rfc/rfc5997.txt- packet types.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- Request Authenticator
--
../data/rfc/rfc5997.txt-DeKok Informational [Page 8]
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-RFC 5997 Status-Server Practices August 2010
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt: The Response Authenticator field of an Accounting-Response packet
../data/rfc/rfc5997.txt- sent in response to Status-Server queries MUST be generated using the
../data/rfc/rfc5997.txt- same method as used for calculating the Response Authenticator of the
../data/rfc/rfc5997.txt: Accounting-Response sent in response to an Accounting-Request, with
../data/rfc/rfc5997.txt- the Status-Server Request Authenticator taking the place of the
../data/rfc/rfc5997.txt: Accounting-Request Request Authenticator.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- Note that when a server responds to a Status-Server request, it MUST
../data/rfc/rfc5997.txt- NOT send more than one Response packet.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- Response Authenticator
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- The value of the Authenticator field in Access-Accept or
../data/rfc/rfc5997.txt: Accounting-Response packets is called the Response
../data/rfc/rfc5997.txt- Authenticator, and contains a one-way MD5 hash calculated over
../data/rfc/rfc5997.txt- a stream of octets consisting of: the RADIUS packet, beginning
../data/rfc/rfc5997.txt- with the Code field, including the Identifier, the Length, the
../data/rfc/rfc5997.txt- Request Authenticator field from the Status-Server packet, and
../data/rfc/rfc5997.txt- the response Attributes (if any), followed by the shared
--
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- Other attributes SHOULD NOT be included in a Status-Server packet,
../data/rfc/rfc5997.txt- and MUST be ignored if they are included. User authentication
../data/rfc/rfc5997.txt- credentials such as User-Name, User-Password, CHAP-Password,
../data/rfc/rfc5997.txt- EAP-Message MUST NOT appear in a Status-Server packet sent to a
../data/rfc/rfc5997.txt: RADIUS authentication port. User or NAS accounting attributes such
../data/rfc/rfc5997.txt- as Acct-Session-Id, Acct-Status-Type, Acct-Input-Octets MUST NOT
../data/rfc/rfc5997.txt: appear in a Status-Server packet sent to a RADIUS accounting port.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- The Access-Accept MAY contain a Reply-Message or Message-
../data/rfc/rfc5997.txt- Authenticator attribute. It SHOULD NOT contain other attributes.
../data/rfc/rfc5997.txt: The Accounting-Response packets sent in response to a Status-Server
../data/rfc/rfc5997.txt- query SHOULD NOT contain any attributes. As the intent is to
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-
--
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-RFC 5997 Status-Server Practices August 2010
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- implement a simple query instead of user authentication or
../data/rfc/rfc5997.txt: accounting, there is little reason to include other attributes in
../data/rfc/rfc5997.txt- either the query or the corresponding response.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- Examples of Status-Server packet flows are given below in Section 6.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-3.1. Single Definition for Status-Server
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt: When sent to a RADIUS accounting port, the contents of the Status-
../data/rfc/rfc5997.txt- Server packets are calculated as described above. That is, even
../data/rfc/rfc5997.txt: though the packets are being sent to an accounting port, they are not
../data/rfc/rfc5997.txt: created using the same method as is used for Accounting-Requests.
../data/rfc/rfc5997.txt- This difference has a number of benefits.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- Having a single definition for Status-Server packets is simpler than
../data/rfc/rfc5997.txt- having different definitions for different destination ports. In
../data/rfc/rfc5997.txt- addition, if we were to define Status-Server as being similar to
../data/rfc/rfc5997.txt: Accounting-Request but containing no attributes, then those packets
../data/rfc/rfc5997.txt- could be trivially forged.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- We therefore define Status-Server consistently, and vary the response
../data/rfc/rfc5997.txt- packets depending on the port to which the request is sent. When
../data/rfc/rfc5997.txt- sent to an authentication port, the response to a Status-Server query
../data/rfc/rfc5997.txt: is an Access-Accept packet. When sent to an accounting port, the
../data/rfc/rfc5997.txt: response to a Status-Server query is an Accounting-Response packet.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-4. Implementation Notes
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- There are a number of considerations to take into account when
../data/rfc/rfc5997.txt- implementing support for Status-Server. This section describes
../data/rfc/rfc5997.txt- implementation details and requirements for RADIUS clients and
../data/rfc/rfc5997.txt- servers that support Status-Server.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt: The following text applies to the authentication and accounting
../data/rfc/rfc5997.txt- ports. We use the generic terms below to simplify the discussion:
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- * Request packet
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- An Access-Request packet sent to an authentication port or an
../data/rfc/rfc5997.txt: Accounting-Request packet sent to an accounting port.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- * Response packet
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- An Access-Accept, Access-Challenge, or Access-Reject packet
../data/rfc/rfc5997.txt: sent from an authentication port or an Accounting-Response
../data/rfc/rfc5997.txt: packet sent from an accounting port.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-
--
../data/rfc/rfc5997.txt- We also refer to "client" as the originator of the Status-Server
../data/rfc/rfc5997.txt- packet, and "server" as the receiver of that packet and the
../data/rfc/rfc5997.txt- originator of the Response packet.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- Using generic terms to describe the Status-Server conversations is
../data/rfc/rfc5997.txt: simpler than duplicating the text for authentication and accounting
../data/rfc/rfc5997.txt- packets.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-4.1. Client Requirements
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- Clients SHOULD permit administrators to globally enable or disable
--
../data/rfc/rfc5997.txt- Other clients MAY choose to send Status-Server requests from a unique
../data/rfc/rfc5997.txt- source port that is not used to send Request packets.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- The above suggestion for a unique source port for Status-Server
../data/rfc/rfc5997.txt- packets aids in matching responses to requests. Since the response
../data/rfc/rfc5997.txt: to a Status-Server packet is an Access-Accept or Accounting-Response
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-DeKok Informational [Page 11]
../data/rfc/rfc5997.txt-
--
../data/rfc/rfc5997.txt- field of the packet matters less than the fact that a valid, signed
../data/rfc/rfc5997.txt- response has been received.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- That is, prior to accepting the response as valid, the client should
../data/rfc/rfc5997.txt- check that the Response packet Code field is either Access-Accept (2)
../data/rfc/rfc5997.txt: or Accounting-Response (5). If the Code does not match any of these
../data/rfc/rfc5997.txt- values, the packet MUST be silently discarded. The client MUST then
../data/rfc/rfc5997.txt- validate the Response Authenticator via the algorithm given above in
../data/rfc/rfc5997.txt- Section 3. If the Response Authenticator is not valid, the packet
../data/rfc/rfc5997.txt- MUST be silently discarded. If the Response Authenticator is valid,
../data/rfc/rfc5997.txt- then the packet MUST be deemed to be a valid response from the
--
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- We note that [RFC2865], Section 3, defines a number of RADIUS Codes,
../data/rfc/rfc5997.txt- but does not make statements about which Codes are valid for
../data/rfc/rfc5997.txt- port 1812. In contrast, [RFC2866], Section 3, specifies that only
../data/rfc/rfc5997.txt: RADIUS Accounting packets are to be sent to port 1813. This
../data/rfc/rfc5997.txt- specification is compatible with [RFC2865], as it uses a known Code
../data/rfc/rfc5997.txt- for packets to port 1812. This specification is not compatible with
../data/rfc/rfc5997.txt- [RFC2866], as it adds a new Code (Status-Server) that is valid for
../data/rfc/rfc5997.txt- port 1812. However, as the category of [RFC2866] is Informational,
../data/rfc/rfc5997.txt- this conflict is acceptable.
--
../data/rfc/rfc5997.txt- connection to that database is down. Or, it may happen when the
../data/rfc/rfc5997.txt- accepted load on the server is lower than the offered load.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- Some server implementations require that Access-Request packets be
../data/rfc/rfc5997.txt- accepted only on "authentication" ports (e.g., 1812/udp), and that
../data/rfc/rfc5997.txt: Accounting-Request packets be accepted only on "accounting" ports
../data/rfc/rfc5997.txt- (e.g., 1813/udp). Those implementations SHOULD reply to Status-
../data/rfc/rfc5997.txt- Server packets sent to an "authentication" port with an Access-Accept
../data/rfc/rfc5997.txt- packet and SHOULD reply to Status-Server packets sent to an
../data/rfc/rfc5997.txt: "accounting" port with an Accounting-Response packet.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-DeKok Informational [Page 13]
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-RFC 5997 Status-Server Practices August 2010
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- Some server implementations accept both Access-Request and
../data/rfc/rfc5997.txt: Accounting-Request packets on the same port, and they do not
../data/rfc/rfc5997.txt: distinguish between "authentication only" ports and "accounting only"
../data/rfc/rfc5997.txt- ports. Those implementations SHOULD reply to Status-Server packets
../data/rfc/rfc5997.txt- with an Access-Accept packet.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- The server MAY increment packet counters as a result of receiving a
../data/rfc/rfc5997.txt- Status-Server packet or sending a Response packet. The server SHOULD
--
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-4.3. Failover with Status-Server
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- A client may wish to "failover" from one proxy to another in the
../data/rfc/rfc5997.txt- event that it does not receive a response to an Access-Request or
../data/rfc/rfc5997.txt: Accounting-Request. In order to determine whether the lack of
../data/rfc/rfc5997.txt- response is due to a problem with the proxy or a downstream server,
../data/rfc/rfc5997.txt- the client can send periodic Status-Server packets to a proxy after
../data/rfc/rfc5997.txt- the lack of a response.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- These packets will help the client determine if the failure was due
--
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- Once the server has been deemed responsive, normal RADIUS requests
../data/rfc/rfc5997.txt- may be sent to it again. This determination should be made
../data/rfc/rfc5997.txt- separately for each server with which the client has a relationship.
../data/rfc/rfc5997.txt- The same algorithm SHOULD be used for both authentication and
../data/rfc/rfc5997.txt: accounting ports. The client MUST treat each destination (IP, port)
../data/rfc/rfc5997.txt- combination as a unique server for the purposes of this
../data/rfc/rfc5997.txt- determination.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- Clients SHOULD use a retransmission mechanism similar to that given
../data/rfc/rfc5997.txt- in Section 2.2.1 of [RFC5080]. If a reliable transport is used for
--
../data/rfc/rfc5997.txt- The following table provides a guide to which attributes may be found
../data/rfc/rfc5997.txt- in Status-Server packets, and in what quantity. Attributes other
../data/rfc/rfc5997.txt- than the ones listed below SHOULD NOT be found in a Status-Server
../data/rfc/rfc5997.txt- packet.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt: Status- Access- Accounting-
../data/rfc/rfc5997.txt- Server Accept Response # Attribute
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- 0 0 0 1 User-Name
../data/rfc/rfc5997.txt- 0 0 0 2 User-Password
../data/rfc/rfc5997.txt- 0 0 0 3 CHAP-Password
--
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-6. Examples
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- A few examples are presented to illustrate the flow of packets to
../data/rfc/rfc5997.txt: both the authentication and accounting ports. These examples are not
../data/rfc/rfc5997.txt- intended to be exhaustive; many others are possible. Hexadecimal
../data/rfc/rfc5997.txt- dumps of the example packets are given in network byte order, using
../data/rfc/rfc5997.txt- the shared secret "xyzzy5461".
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-6.1. Minimal Query to Authentication Port
--
../data/rfc/rfc5997.txt-DeKok Informational [Page 19]
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-RFC 5997 Status-Server Practices August 2010
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt:6.2. Minimal Query to Accounting Port
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- The NAS sends a Status-Server UDP packet with minimal content to a
../data/rfc/rfc5997.txt- RADIUS server on port 1813.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- The Request Authenticator is a 16-octet random number generated by
--
../data/rfc/rfc5997.txt- the shared secret.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- 02 b3 00 14 0f 6f 92 14 5f 10 7e 2f 50 4e 86 0a
../data/rfc/rfc5997.txt- 48 60 66 9c
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt: 1 Code = Accounting-Response (5)
../data/rfc/rfc5997.txt- 1 ID = 179
../data/rfc/rfc5997.txt- 2 Length = 20
../data/rfc/rfc5997.txt- 16 Request Authenticator
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- Attributes:
--
../data/rfc/rfc5997.txt- [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
../data/rfc/rfc5997.txt- "Remote Authentication Dial In User Service (RADIUS)",
../data/rfc/rfc5997.txt- RFC 2865, June 2000.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
../data/rfc/rfc5997.txt: Accounting (AAA) Transport Profile", RFC 3539, June 2003.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
../data/rfc/rfc5997.txt- "Randomness Requirements for Security", BCP 106,
../data/rfc/rfc5997.txt- RFC 4086, June 2005.
../data/rfc/rfc5997.txt-
--
../data/rfc/rfc5997.txt- Dial In User Service (RADIUS) Implementation Issues and
../data/rfc/rfc5997.txt- Suggested Fixes", RFC 5080, December 2007.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-8.2. Informative References
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
../data/rfc/rfc5997.txt- Dial In User Service) Support For Extensible
../data/rfc/rfc5997.txt- Authentication Protocol (EAP)", RFC 3579, September 2003.
../data/rfc/rfc5997.txt-
--
../data/rfc/rfc5997.txt- RFC 4668, August 2006.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- [RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6",
../data/rfc/rfc5997.txt- RFC 4669, August 2006.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt: [RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6",
../data/rfc/rfc5997.txt- RFC 4670, August 2006.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-DeKok Informational [Page 23]
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-RFC 5997 Status-Server Practices August 2010
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt: [RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6",
../data/rfc/rfc5997.txt- RFC 4671, August 2006.
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt-Acknowledgments
../data/rfc/rfc5997.txt-
../data/rfc/rfc5997.txt- Parts of the text in Section 3 defining the Request and Response
--
../data/rfc/rfc3600.txt--------- Transport Layer Security (TLS) Extensions 3546*
../data/rfc/rfc3600.txt--------- Enhanced Compressed RTP (CRTP) for Links with High 3545*
../data/rfc/rfc3600.txt- Delay, Packet Loss and Reordering
../data/rfc/rfc3600.txt-IPCOM-PPP IP Header Compression over PPP 3544*
../data/rfc/rfc3600.txt--------- Registration Revocation in Mobile IPv4 3543*
../data/rfc/rfc3600.txt:-------- Authentication, Authorization and Accounting (AAA) 3539*
../data/rfc/rfc3600.txt- Transport Profile
../data/rfc/rfc3600.txt--------- Wrapping a Hashed Message Authentication Code (HMAC) 3537*
../data/rfc/rfc3600.txt- key with a Triple-Data Encryption Standard
../data/rfc/rfc3600.txt- (DES) Key or an Advanced Encryption Standard (AES)
../data/rfc/rfc3600.txt- Key
--
../data/rfc/rfc3600.txt-WEBDAV HTTP Extensions for Distributed Authoring -- WEBDAV 2518
../data/rfc/rfc3600.txt-ATM-MIBMAN Definitions of Managed Objects for ATM Management 2515
../data/rfc/rfc3600.txt-ATM-TC-OID Definitions of Textual Conventions and OBJECT- 2514
../data/rfc/rfc3600.txt- IDENTITIES for ATM Management
../data/rfc/rfc3600.txt--------- Managed Objects for Controlling the Collection 2513
../data/rfc/rfc3600.txt: and Storage of Accounting Information for
../data/rfc/rfc3600.txt- Connection-Oriented Networks
../data/rfc/rfc3600.txt:-------- Accounting Information for ATM Networks 2512
../data/rfc/rfc3600.txt-X.509-CRMF Internet X.509 Certificate Request Message Format 2511
../data/rfc/rfc3600.txt-PKICMP Internet X.509 Public Key Infrastructure Certificate 2510
../data/rfc/rfc3600.txt- Management Protocols
../data/rfc/rfc3600.txt--------- Compressing IP/UDP/RTP Headers for Low-Speed Serial 2508
../data/rfc/rfc3600.txt- Links
--
../data/rfc/rfc3600.txt- Control Protocol Transport Mapping
../data/rfc/rfc3600.txt--------- Select and Sort Extensions for the Service Location 3421*
../data/rfc/rfc3600.txt- Protocol (SLP)
../data/rfc/rfc3600.txt--------- The Application Exchange (APEX) Presence Service 3343*
../data/rfc/rfc3600.txt--------- Dual Stack Hosts Using "Bump-in-the-API" (BIA) 3338
../data/rfc/rfc3600.txt:-------- Policy-Based Accounting 3334
../data/rfc/rfc3600.txt--------- PGM Reliable Transport Protocol Specification 3208
../data/rfc/rfc3600.txt--------- Domain Security Services using S/MIME 3183
../data/rfc/rfc3600.txt-SMX Script MIB Extensibility Protocol Version 1.1 3179
../data/rfc/rfc3600.txt--------- ISO/IEC 9798-3 Authentication SASL Mechanism 3163
../data/rfc/rfc3600.txt--------- Electronic Signature Policies 3125
--
../data/rfc/rfc4216.txt- - Similarly, the inclusion of the RRO object in the Resv message
../data/rfc/rfc4216.txt- recording sub-objects such as interface IPv4/v6 address (if not
../data/rfc/rfc4216.txt- hidden), AS number, a label, a node-id (when required), etc.
../data/rfc/rfc4216.txt- - Inter-AS specific attributes as discussed in section 5 of this
../data/rfc/rfc4216.txt- document including, for example, inter-AS MPLS TE tunnel
../data/rfc/rfc4216.txt: accounting records across each AS segment.
../data/rfc/rfc4216.txt-
../data/rfc/rfc4216.txt-5.1.10.2. Inter-AS MPLS TE Fault Management Requirements
../data/rfc/rfc4216.txt-
../data/rfc/rfc4216.txt- In a MPLS network, an SP wants to detect both control plane and data
../data/rfc/rfc4216.txt- plane failures. But tools for fault detection over LSPs haven't been
--
../data/rfc/rfc740.txt-RFC 740 RTB 42423 22 Nov 77
../data/rfc/rfc740.txt-NETRJS Protocol
../data/rfc/rfc740.txt-
../data/rfc/rfc740.txt-
../data/rfc/rfc740.txt-
../data/rfc/rfc740.txt: system and accounting messages will be sent.
../data/rfc/rfc740.txt-
../data/rfc/rfc740.txt- (b) On an input channel, CAN causes RJS to ignore
../data/rfc/rfc740.txt- the job currently being read. However, the channel
../data/rfc/rfc740.txt- is not aborted as a result, and RJS will continue
../data/rfc/rfc740.txt- reading in jobs on the channel.
--
../data/rfc/rfc740.txt- the compressed format for printer and punch output. See
../data/rfc/rfc740.txt- Reference 9 for discussion of the virtues of compression.
../data/rfc/rfc740.txt-
../data/rfc/rfc740.txt- 2. Automatic Coldstart Job Resubmission
../data/rfc/rfc740.txt-
../data/rfc/rfc740.txt: If "R" (Restart) is specified in the accounting field on the
../data/rfc/rfc740.txt- JOB card and if this option is chosen, RJS will automatically
../data/rfc/rfc740.txt- resubmit the job from the beginning if the server operating
../data/rfc/rfc740.txt- system should be "coldstarted" before all output from the job
../data/rfc/rfc740.txt- is returned. Otherwise, the job will be lost and must be
../data/rfc/rfc740.txt- resubmitted from the remote terminal in case of a coldstart.
--
../data/rfc/rfc6581.txt- 4.1. Standardization of RDMA Read Parameter Configuration .......7
../data/rfc/rfc6581.txt- 4.2. Enabling MPA Mode ..........................................9
../data/rfc/rfc6581.txt- 4.3. Lack of Explicit RTR in MPA Request/Reply Exchange ........10
../data/rfc/rfc6581.txt- 4.4. Limitations on ULP Workaround .............................11
../data/rfc/rfc6581.txt- 4.4.1. Transport Neutral APIs .............................11
../data/rfc/rfc6581.txt: 4.4.2. Work/Completion Queue Accounting ...................11
../data/rfc/rfc6581.txt- 4.4.3. Host-based Implementation of MPA Fencing ...........12
../data/rfc/rfc6581.txt- 5. Enhanced MPA Connection Establishment ..........................13
../data/rfc/rfc6581.txt- 6. Enhanced MPA Request/Reply Frames ..............................14
../data/rfc/rfc6581.txt- 7. Enhanced SCTP Session Control Chunks ...........................15
../data/rfc/rfc6581.txt- 8. MPA Error Reporting ............................................16
--
../data/rfc/rfc6581.txt- There are three factors that make this workaround unsuitable for many
../data/rfc/rfc6581.txt- peer-to-peer applications:
../data/rfc/rfc6581.txt-
../data/rfc/rfc6581.txt- o Transport-Neutral APIs.
../data/rfc/rfc6581.txt-
../data/rfc/rfc6581.txt: o Work/Completion Queue Accounting.
../data/rfc/rfc6581.txt-
../data/rfc/rfc6581.txt- o Host-based implementation of MPA Fencing.
../data/rfc/rfc6581.txt-
../data/rfc/rfc6581.txt-4.4.1. Transport-Neutral APIs
../data/rfc/rfc6581.txt-
--
../data/rfc/rfc6581.txt- transport-neutral RDMA operations, allowing lower software layers to
../data/rfc/rfc6581.txt- translate to transport and device specifics. Having a distinct extra
../data/rfc/rfc6581.txt- message that is required only for one transport undermines the
../data/rfc/rfc6581.txt- application's goal of being transport neutral.
../data/rfc/rfc6581.txt-
../data/rfc/rfc6581.txt:4.4.2. Work/Completion Queue Accounting
../data/rfc/rfc6581.txt-
../data/rfc/rfc6581.txt- RDMA local APIs conventionally use Work Queues to submit requests
../data/rfc/rfc6581.txt- (Work Queue elements or WQEs) and to asynchronously receive
../data/rfc/rfc6581.txt- completions (in Completion Queues or CQs).
../data/rfc/rfc6581.txt-
--
../data/rfc/rfc5608.txt- passwords (with the User-Password Attribute), but other secure
../data/rfc/rfc5608.txt- transports could use other authentication mechanisms, and would
../data/rfc/rfc5608.txt- include RADIUS authentication attributes appropriate for that
../data/rfc/rfc5608.txt- mechanism instead of User-Password.
../data/rfc/rfc5608.txt-
../data/rfc/rfc5608.txt: This document does not describe the usage of RADIUS Accounting or
../data/rfc/rfc5608.txt- Dynamic RADIUS Re-Authorization. Such RADIUS usages are not
../data/rfc/rfc5608.txt- currently envisioned for SNMP, and are beyond the scope of this
../data/rfc/rfc5608.txt- document.
../data/rfc/rfc5608.txt-
../data/rfc/rfc5608.txt-
--
../data/rfc/rfc6158.txt- Documents" [RFC4181], it is expected that authors will check their
../data/rfc/rfc6158.txt- document against the guidelines in this document prior to publication
../data/rfc/rfc6158.txt- or requesting review (such as an "Expert Review" described in
../data/rfc/rfc6158.txt- [RFC3575]). Similarly, it is expected that this document will be
../data/rfc/rfc6158.txt- used by reviewers (such as WG participants or the Authentication,
../data/rfc/rfc6158.txt: Authorization, and Accounting (AAA) Doctors [DOCTORS]), resulting in
../data/rfc/rfc6158.txt- an improvement in the consistency of reviews.
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt- In order to meet these objectives, this document needs to cover not
../data/rfc/rfc6158.txt- only the science of attribute design but also the art. Therefore, in
../data/rfc/rfc6158.txt- addition to covering the most frequently encountered issues, this
--
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt- Network Access Server (NAS)
../data/rfc/rfc6158.txt- A device that provides an access service for a user to a network.
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt- RADIUS server
../data/rfc/rfc6158.txt: A RADIUS authentication, authorization, and accounting (AAA)
../data/rfc/rfc6158.txt- server is an entity that provides one or more AAA services to a
../data/rfc/rfc6158.txt- NAS.
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt- Standard space
../data/rfc/rfc6158.txt- Codes in the RADIUS Attribute Type Space that are allocated by
--
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt-1.3. Applicability
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt- The advice in this document applies to RADIUS attributes used to
../data/rfc/rfc6158.txt: encode service-provisioning, authentication, or accounting data based
../data/rfc/rfc6158.txt- on the attribute encodings and data formats defined in RFC 2865
../data/rfc/rfc6158.txt- [RFC2865], RFC 2866 [RFC2866], and subsequent RADIUS RFCs.
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt- Since this document represents a Best Current Practice, it does not
../data/rfc/rfc6158.txt- update or deprecate existing standards. As a result, uses of the
--
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt-2. Guidelines
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt- The RADIUS protocol as defined in [RFC2865] and [RFC2866] uses
../data/rfc/rfc6158.txt- elements known as attributes in order to represent authentication,
../data/rfc/rfc6158.txt: authorization, and accounting data.
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt-
--
../data/rfc/rfc6158.txt- fragmented UDP packets, making it difficult to deploy RADIUS in a
../data/rfc/rfc6158.txt- network where those devices are deployed. We RECOMMEND that RADIUS
../data/rfc/rfc6158.txt- messages be kept as small possible.
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt- If a situation is envisaged where it may be necessary to carry
../data/rfc/rfc6158.txt: authentication, authorization, or accounting data in a packet larger
../data/rfc/rfc6158.txt- than 4096 octets, then one of the following approaches is
../data/rfc/rfc6158.txt- RECOMMENDED:
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt- 1. Utilization of a sequence of packets.
../data/rfc/rfc6158.txt- For RADIUS authentication, a sequence of Access-
--
../data/rfc/rfc6158.txt- Filter-Rule Attribute defined in [RFC4849] is not permitted in
../data/rfc/rfc6158.txt- an Access-Challenge packet, nor is a mechanism specified to
../data/rfc/rfc6158.txt- allow a set of NAS-Filter-Rule Attributes to be split across
../data/rfc/rfc6158.txt- an Access-Request/Access-Challenge sequence.
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt: In the case of RADIUS accounting, transporting large amounts
../data/rfc/rfc6158.txt: of data would require a sequence of Accounting-Request
../data/rfc/rfc6158.txt- packets. This is a non-trivial change to RADIUS, since RADIUS
../data/rfc/rfc6158.txt: accounting clients would need to be modified to split the
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt-DeKok & Weber Best Current Practice [Page 13]
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt-RFC 6158 RADIUS Design Guidelines March 2011
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt: attribute stream across multiple Accounting-Requests, and
../data/rfc/rfc6158.txt- billing servers would need to be modified to reassemble and
../data/rfc/rfc6158.txt- interpret the attribute stream.
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt- 2. Utilization of names rather than values.
../data/rfc/rfc6158.txt- Where an attribute relates to a policy that could conceivably
--
../data/rfc/rfc6158.txt- guidelines for Expert Reviewers appointed as described in [RFC3575].
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt-5. Security Considerations
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt- This specification provides guidelines for the design of RADIUS
../data/rfc/rfc6158.txt: attributes used in authentication, authorization, and accounting.
../data/rfc/rfc6158.txt- Threats and security issues for this application are described in
../data/rfc/rfc6158.txt- [RFC3579] and [RFC3580]; security issues encountered in roaming are
../data/rfc/rfc6158.txt- described in [RFC2607].
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt- Obfuscation of RADIUS attributes on a per-attribute basis is
--
../data/rfc/rfc6158.txt- Attributes", RFC 2548, March 1999.
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt- [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
../data/rfc/rfc6158.txt- Implementation in Roaming", RFC 2607, June 1999.
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt- [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J.,
../data/rfc/rfc6158.txt- Holdrege, M., and I. Goyret, "RADIUS Attributes for
../data/rfc/rfc6158.txt- Tunnel Protocol Support", RFC 2868, June 2000.
../data/rfc/rfc6158.txt-
--
../data/rfc/rfc6158.txt- This restriction includes new commands created by overloading
../data/rfc/rfc6158.txt- the Service-Type Attribute to define new values that modify the
../data/rfc/rfc6158.txt- functionality of Access-Request packets.
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt- * Using RADIUS as a transport protocol for data unrelated to
../data/rfc/rfc6158.txt: authentication, authorization, or accounting.
../data/rfc/rfc6158.txt- Using RADIUS to transport authentication methods such as EAP is
../data/rfc/rfc6158.txt- explicitly permitted, even if those methods require the
../data/rfc/rfc6158.txt- transport of relatively large amounts of data. Transport of
../data/rfc/rfc6158.txt- opaque data relating to AAA is also permitted, as discussed in
../data/rfc/rfc6158.txt- Section 3.2.3. However, if the specification does not relate to
--
../data/rfc/rfc6158.txt- optionally other information.
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt- For example, "28800 V42BIS/LAPM" or "52000/31200 V90"
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt- More than one Connect-Info attribute may be present in an
../data/rfc/rfc6158.txt: Accounting-Request packet to accommodate expected efforts by ITU
../data/rfc/rfc6158.txt- to have modems report more connection information in a standard
../data/rfc/rfc6158.txt- format that might exceed 252 octets.
../data/rfc/rfc6158.txt-
../data/rfc/rfc6158.txt- This attribute contains no encrypted component and is not directly
../data/rfc/rfc6158.txt- involved in authentication. The individual sub-fields could
--
../data/rfc/rfc5394.txt- - Support for many policies
../data/rfc/rfc5394.txt- The mechanisms must include support for many policies and policy
../data/rfc/rfc5394.txt- configurations. In general, the determination and configuration of
../data/rfc/rfc5394.txt- viable policies are the responsibility of the service provider.
../data/rfc/rfc5394.txt-
../data/rfc/rfc5394.txt: - Provision for monitoring and accounting information
../data/rfc/rfc5394.txt- The mechanisms must include support for monitoring policy state and
../data/rfc/rfc5394.txt- provide access information. In particular, mechanisms must provide
../data/rfc/rfc5394.txt: usage and access information that may be used for accounting
../data/rfc/rfc5394.txt- purposes.
../data/rfc/rfc5394.txt-
../data/rfc/rfc5394.txt- - Fault tolerance and recovery
../data/rfc/rfc5394.txt- The mechanisms must include provisions for fault tolerance and
../data/rfc/rfc5394.txt- recovery from failure cases such as failure of PCC/PCE PDPs,
--
../data/rfc/rfc1935.txt-
../data/rfc/rfc1935.txt-Starting at the Center
../data/rfc/rfc1935.txt-
../data/rfc/rfc1935.txt- For real confusion, start trying to get agreement on what is part of
../data/rfc/rfc1935.txt- the Internet: NSFNET? CIX? Your company's internal network?
../data/rfc/rfc1935.txt: Prodigy? FidoNet? The mainframe in accounting? Some people would
../data/rfc/rfc1935.txt- include all of the above, and perhaps even consider excluding
../data/rfc/rfc1935.txt- anything politically incorrect. Others have cast doubts on each of
../data/rfc/rfc1935.txt- the above.
../data/rfc/rfc1935.txt-
../data/rfc/rfc1935.txt- Let's start some place almost everyone would agree is on the
--
../data/rfc/rfc1935.txt- In addition to computers and networks that fit these classifications,
../data/rfc/rfc1935.txt- there are also LANs, mainframes, and BBSes that don't exchange any
../data/rfc/rfc1935.txt- services with other networks or computers; not even mail. These
../data/rfc/rfc1935.txt- systems are outside the Matrix. For example, many companies have an
../data/rfc/rfc1935.txt- AppleTalk LAN in marketing, a Novell NetWare LAN in management, and a
../data/rfc/rfc1935.txt: mainframe in accounting that aren't connected to talk to anything
../data/rfc/rfc1935.txt- else. In addition, there are a few large networks such as France's
../data/rfc/rfc1935.txt- Teletel (commonly known as Minitel) that support very large user
../data/rfc/rfc1935.txt- populations but don't communicate with anything else. These are all
../data/rfc/rfc1935.txt- currently outside all our Chinese boxes of the core Internet, the
../data/rfc/rfc1935.txt- consumer Internet, and the Matrix.
--
../data/rfc/rfc532.txt- on any of our 7 or 9-track tape drives. Each individual file
../data/rfc/rfc532.txt- transfer is handled by a separate process on the B6700 and the user
../data/rfc/rfc532.txt- is charged for the processor, I/O, core, and (if any) tape charges
../data/rfc/rfc532.txt- incurred by this process (note that these charges are quite minimal).
../data/rfc/rfc532.txt- Each of these transfer processes is given a separate "job" number and
../data/rfc/rfc532.txt: is therefore billed separately for each transfer by our accounting
../data/rfc/rfc532.txt- system.
../data/rfc/rfc532.txt-
../data/rfc/rfc532.txt- Please note that we have implemented FTP as defined in RFC# 354 (July
../data/rfc/rfc532.txt- 8, 1972) except as noted.
../data/rfc/rfc532.txt-
--
../data/rfc/rfc1674.txt- commercial users. Security services which may optionally be expected
../data/rfc/rfc1674.txt- from a Layer 3 entity such as IPng include peer entity
../data/rfc/rfc1674.txt- authentication, data confidentiality, traffic flow confidentiality,
../data/rfc/rfc1674.txt- data integrity and location confidentiality.
../data/rfc/rfc1674.txt-
../data/rfc/rfc1674.txt:Accounting
../data/rfc/rfc1674.txt-
../data/rfc/rfc1674.txt: The ability to do accounting at Layer 3 is a requirement. The CDPD
../data/rfc/rfc1674.txt: specification can be used as a model of the type of accounting
../data/rfc/rfc1674.txt- services that we need.
../data/rfc/rfc1674.txt-
../data/rfc/rfc1674.txt-
../data/rfc/rfc1674.txt-
../data/rfc/rfc1674.txt-
--
../data/rfc/rfc3583.txt-3.4. Standard requirements
../data/rfc/rfc3583.txt-
../data/rfc/rfc3583.txt- The QoS solution for Mobile IP SHOULD satisfy standard requirements
../data/rfc/rfc3583.txt- such as scalability, security, conservation of wireless bandwidth,
../data/rfc/rfc3583.txt- low processing overhead on mobile terminals, providing hooks for
../data/rfc/rfc3583.txt: authorization and accounting, and robustness against failures of any
../data/rfc/rfc3583.txt- Mobile IP-specific QoS components in the network. While it is not
../data/rfc/rfc3583.txt- possible to set quantitative targets for these desirable properties,
../data/rfc/rfc3583.txt- the QoS solution MUST be evaluated against these criteria.
../data/rfc/rfc3583.txt-
../data/rfc/rfc3583.txt-4. Security Considerations
--
../data/rfc/rfc1306.txt- We developed our support for circuit switched services around a
../data/rfc/rfc1306.txt- simple model of a switched network. At some point in the path
../data/rfc/rfc1306.txt- between two hosts, there is a switched network connection. This
../data/rfc/rfc1306.txt- connection is likely to connect two enterprise networks operated by
../data/rfc/rfc1306.txt- the same organization. Administrative overlap between the two
../data/rfc/rfc1306.txt: networks is useful for accounting and configuration purposes. We
../data/rfc/rfc1306.txt- believe that with further investigation circuit switched network
../data/rfc/rfc1306.txt- support could be extended to multiple switched links in an internet
../data/rfc/rfc1306.txt- environment.
../data/rfc/rfc1306.txt-
../data/rfc/rfc1306.txt- The switch which makes the network connection operates on a "by-
--
../data/rfc/rfc1306.txt- bandwidth interactive traffic, change the type-of-service (thus
../data/rfc/rfc1306.txt- activating the switched connection) for bulk transfers, and then
../data/rfc/rfc1306.txt- release the switch upon returning to interactive traffic.
../data/rfc/rfc1306.txt-
../data/rfc/rfc1306.txt- Putting this feature into the kernel also allows strong control over
../data/rfc/rfc1306.txt: when and how the switched link can be used, keeping accounting
../data/rfc/rfc1306.txt- information, and limiting multiple use access to the switched link.
../data/rfc/rfc1306.txt-
../data/rfc/rfc1306.txt- The disadvantage is that significant kernel modifications are
../data/rfc/rfc1306.txt- required, and some implementation details can be very difficult to
../data/rfc/rfc1306.txt- handle.
--
../data/rfc/rfc7933.txt- at the proper level. Therefore, there is a need to either include
../data/rfc/rfc7933.txt- some location semantics in the data chunks so as to properly
../data/rfc/rfc7933.txt- assess the throughput to a specific location or to design a
../data/rfc/rfc7933.txt- different mechanism to evaluate the available network bandwidth.
../data/rfc/rfc7933.txt-
../data/rfc/rfc7933.txt: o The typical issue of access control and accounting happens in this
../data/rfc/rfc7933.txt- context, where chunks can be cached in the network outside of the
../data/rfc/rfc7933.txt- administrative control of the content publisher. It might be a
../data/rfc/rfc7933.txt- requirement from the owner of the video stream that access to
../data/rfc/rfc7933.txt- these data chunks needs to be accounted/billed/monitored.
../data/rfc/rfc7933.txt-
--
../data/rfc/rfc7933.txt-
../data/rfc/rfc7933.txt-8. Digital Rights Management in ICN
../data/rfc/rfc7933.txt-
../data/rfc/rfc7933.txt- This section discusses the need for DRM functionalities for
../data/rfc/rfc7933.txt- multimedia streaming over ICN. It focuses on two possible
../data/rfc/rfc7933.txt: approaches: modifying Authentication, Authorization, and Accounting
../data/rfc/rfc7933.txt- (AAA) to support DRM in ICN and using Broadcast Encryption.
../data/rfc/rfc7933.txt-
../data/rfc/rfc7933.txt- It is assumed that ICN will be used heavily for digital content
../data/rfc/rfc7933.txt- dissemination. It is vital to consider DRM for digital content
../data/rfc/rfc7933.txt- distribution. In today's Internet, there are two predominant classes
--
../data/rfc/rfc1752.txt- industries that many feel will be the major providers of data
../data/rfc/rfc1752.txt- networking services in the future; the cable TV industry [Vecchi94],
../data/rfc/rfc1752.txt- the cellular industry [Taylor94], and the electric power industry
../data/rfc/rfc1752.txt- [Skelton94]. In addition, we received papers that dealt with
../data/rfc/rfc1752.txt- military applications [Adam94, Syming94, Green94], ATM [Brazd94],
../data/rfc/rfc1752.txt: mobility [Simpson94], accounting [Brown94], routing [Estrin94a,
../data/rfc/rfc1752.txt- Chiappa94], security [Adam94, Bell94b, Brit94, Green94, Vecchi94,
../data/rfc/rfc1752.txt- Flei94], large corporate networking [Britt94, Fleisch94], transition
../data/rfc/rfc1752.txt- [Carpen94a, Heager94], market acceptance [Curran94, Britt94], host
../data/rfc/rfc1752.txt- implementations [Bound94], as well as a number of other issues.
../data/rfc/rfc1752.txt- [Bello94a, Clark94, Ghisel94]
--
../data/rfc/rfc1752.txt- Bellcore, August 1994.
../data/rfc/rfc1752.txt-
../data/rfc/rfc1752.txt- [Britt94] Britton, E., and J. Tavs, "IPng Requirements of Large
../data/rfc/rfc1752.txt- Corporate Networks", RFC 1678, IBM, August 1994.
../data/rfc/rfc1752.txt-
../data/rfc/rfc1752.txt: [Brownl94] Brownlee, J., "Accounting Requirements for IPng", RFC
../data/rfc/rfc1752.txt- 1672, University of Auckland, August 1994.
../data/rfc/rfc1752.txt-
../data/rfc/rfc1752.txt- [Carpen94a] Carpenter, B., "IPng White Paper on Transition and Other
../data/rfc/rfc1752.txt- Considerations", RFC 1671, CERN, August 1994.
../data/rfc/rfc1752.txt-
--
../data/rfc/rfc3512.txt- information an agent will expose.
../data/rfc/rfc3512.txt-
../data/rfc/rfc3512.txt- MIB modules can be thought of as logical models providing one or more
../data/rfc/rfc3512.txt- aspects/views of a subsystem. The objective for all MIB modules
../data/rfc/rfc3512.txt- should be to serve one or more operational requirements such as
../data/rfc/rfc3512.txt: accounting information collection, configuration of one or more parts
../data/rfc/rfc3512.txt- of a system, or fault identification. However, it is important to
../data/rfc/rfc3512.txt- include only those aspects of a subsystem that are proven to be
../data/rfc/rfc3512.txt- operationally useful.
../data/rfc/rfc3512.txt-
../data/rfc/rfc3512.txt- In 1993, one of most widely deployed MIB modules supporting
--
../data/rfc/rfc3512.txt- the function they perform. For example the objects that control
../data/rfc/rfc3512.txt- configuration in the example MIB module in Section 8 include "Cfg" as
../data/rfc/rfc3512.txt- part of the object descriptor, as in bldgHVACCfgDesiredTemp.
../data/rfc/rfc3512.txt-
../data/rfc/rfc3512.txt- This is more fully realized when the object descriptors that include
../data/rfc/rfc3512.txt: the fault, configuration, accounting, performance and security [33]
../data/rfc/rfc3512.txt- abbreviations are combined with an organized OID assignment approach.
../data/rfc/rfc3512.txt- For example, a vendor could create a configuration branch in their
../data/rfc/rfc3512.txt- private enterprises area. In some cases this might be best done on a
../data/rfc/rfc3512.txt- per product basis. Whatever the approach used, "Cfg" might be
../data/rfc/rfc3512.txt- included in every object descriptor in the configuration branch.
--
../data/rfc/rfc2199.txt-Ramos Informational [Page 13]
../data/rfc/rfc2199.txt-
../data/rfc/rfc2199.txt-RFC 2199 Summary of 2100-2199 January 1998
../data/rfc/rfc2199.txt-
../data/rfc/rfc2199.txt-
../data/rfc/rfc2199.txt:2139 Rigney Apr 97 RADIUS Accounting
../data/rfc/rfc2199.txt-
../data/rfc/rfc2199.txt:This document describes a protocol for carrying accounting information
../data/rfc/rfc2199.txt:between a Network Access Server and a shared Accounting Server. This
../data/rfc/rfc2199.txt-memo provides information for the Internet community. This memo does
../data/rfc/rfc2199.txt-not specify an Internet standard of any kind.
../data/rfc/rfc2199.txt-
../data/rfc/rfc2199.txt-
../data/rfc/rfc2199.txt-2138 Rigney Apr 97 Remote Authentication Dial In User
--
../data/rfc/rfc4565.txt- M., Hares, S., and N. Cam Winget, "Light Weight Access
../data/rfc/rfc4565.txt- Point Protocol (LWAPP)", Work in Progress, March 2005.
../data/rfc/rfc4565.txt-
../data/rfc/rfc4565.txt- [RFC3127] Mitton, D., St.Johns, M., Barkley, S., Nelson, D., Patil,
../data/rfc/rfc4565.txt- B., Stevens, M., and B. Wolff, "Authentication,
../data/rfc/rfc4565.txt: Authorization, and Accounting: Protocol Evaluation", RFC
../data/rfc/rfc4565.txt- 3127, June 2001.
../data/rfc/rfc4565.txt-
../data/rfc/rfc4565.txt- [SLAPP] Narasimhan, P., Harkins, D., and S. Ponnuswamy, "SLAPP :
../data/rfc/rfc4565.txt- Secure Light Access Point Protocol", Work in Progress, May
../data/rfc/rfc4565.txt- 2005.
--
../data/rfc/rfc5637.txt- R. Lopez
../data/rfc/rfc5637.txt- University of Murcia
../data/rfc/rfc5637.txt- September 2009
../data/rfc/rfc5637.txt-
../data/rfc/rfc5637.txt-
../data/rfc/rfc5637.txt: Authentication, Authorization, and Accounting (AAA) Goals
../data/rfc/rfc5637.txt- for Mobile IPv6
../data/rfc/rfc5637.txt-
../data/rfc/rfc5637.txt-Abstract
../data/rfc/rfc5637.txt-
../data/rfc/rfc5637.txt- In commercial and enterprise deployments, Mobile IPv6 can be a
../data/rfc/rfc5637.txt- service offered by a Mobility Services Provider (MSP). In this case,
../data/rfc/rfc5637.txt- all protocol operations may need to be explicitly authorized and
../data/rfc/rfc5637.txt- traced, requiring the interaction between Mobile IPv6 and the AAA
../data/rfc/rfc5637.txt- infrastructure. Integrating the Authentication, Authorization, and
../data/rfc/rfc5637.txt: Accounting (AAA) infrastructure (e.g., Network Access Server and AAA
../data/rfc/rfc5637.txt- server) also offers a solution component for Mobile IPv6
../data/rfc/rfc5637.txt- bootstrapping. This document describes various scenarios where a AAA
../data/rfc/rfc5637.txt- interface for Mobile IPv6 is required. Additionally, it lists design
../data/rfc/rfc5637.txt- goals and requirements for such an interface.
../data/rfc/rfc5637.txt-
--
../data/rfc/rfc5637.txt- 4.1. Split Scenario .............................................5
../data/rfc/rfc5637.txt- 4.2. Integrated Scenario ........................................6
../data/rfc/rfc5637.txt- 5. Goals for AAA-HA Interface ......................................6
../data/rfc/rfc5637.txt- 5.1. General Goals ..............................................6
../data/rfc/rfc5637.txt- 5.2. Service Authorization ......................................7
../data/rfc/rfc5637.txt: 5.3. Accounting .................................................8
../data/rfc/rfc5637.txt- 5.4. Mobile Node Authentication .................................8
../data/rfc/rfc5637.txt- 5.5. Provisioning of Configuration Parameters ...................8
../data/rfc/rfc5637.txt- 6. Goals for the AAA-NAS Interface .................................9
../data/rfc/rfc5637.txt- 7. Security Considerations .........................................9
../data/rfc/rfc5637.txt- 8. Acknowledgements ................................................9
--
../data/rfc/rfc5637.txt-
../data/rfc/rfc5637.txt-1. Introduction
../data/rfc/rfc5637.txt-
../data/rfc/rfc5637.txt- Mobile IPv6 [1] provides the basic IP mobility functionality for
../data/rfc/rfc5637.txt- IPv6. When Mobile IPv6 is used in tightly managed environments with
../data/rfc/rfc5637.txt: the use of the AAA (Authentication, Authorization, and Accounting)
../data/rfc/rfc5637.txt- infrastructure, an interface between Mobile IPv6 and AAA protocols
../data/rfc/rfc5637.txt- needs to be defined. Also, two scenarios for bootstrapping Mobile
../data/rfc/rfc5637.txt- IPv6 service [2], i.e., split [3] and integrated [6] scenarios,
../data/rfc/rfc5637.txt- require the specification of a message exchange between the Home
../data/rfc/rfc5637.txt- Agent (HA) and AAA infrastructure for authentication and
--
../data/rfc/rfc5637.txt- address as specified in [6]).
../data/rfc/rfc5637.txt-
../data/rfc/rfc5637.txt- Moreover, in case Mobile IPv6 is a service offered by a Mobility
../data/rfc/rfc5637.txt- Service Provider (MSP), all protocol operations (e.g., home
../data/rfc/rfc5637.txt- registrations) may need to be explicitly authorized and monitored
../data/rfc/rfc5637.txt: (e.g., for accounting purposes). This can be accomplished relying on
../data/rfc/rfc5637.txt- the AAA infrastructure of the Mobility Service Authorizer (MSA) that
../data/rfc/rfc5637.txt- stores user profiles and credentials.
../data/rfc/rfc5637.txt-
../data/rfc/rfc5637.txt-4. Bootstrapping Scenarios
../data/rfc/rfc5637.txt-
--
../data/rfc/rfc5637.txt- G2.12 The HA MUST be able to authenticate the MN through the AAAH
../data/rfc/rfc5637.txt- server in case a pre-shared key is used in IKEv2 for user
../data/rfc/rfc5637.txt- authentication. The exact procedure is part of the solution
../data/rfc/rfc5637.txt- space.
../data/rfc/rfc5637.txt-
../data/rfc/rfc5637.txt:5.3. Accounting
../data/rfc/rfc5637.txt-
../data/rfc/rfc5637.txt: G3.1 The AAA-HA interface MUST support the transfer of accounting
../data/rfc/rfc5637.txt- records needed for service control and charging. These include
../data/rfc/rfc5637.txt- (but may not be limited to): time of binding cache entry
../data/rfc/rfc5637.txt- creation and deletion, octets sent and received by the Mobile
../data/rfc/rfc5637.txt- Node in bi-directional tunneling, etc.
../data/rfc/rfc5637.txt-
--
../data/rfc/rfc3539.txt-Category: Standards Track J. Wood
../data/rfc/rfc3539.txt- Sun Microsystems, Inc.
../data/rfc/rfc3539.txt- June 2003
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt: Authentication, Authorization and Accounting (AAA) Transport Profile
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt-Status of this Memo
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt- This document specifies an Internet standards track protocol for the
../data/rfc/rfc3539.txt- Internet community, and requests discussion and suggestions for
--
../data/rfc/rfc3539.txt- Copyright (C) The Internet Society (2003). All Rights Reserved.
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt-Abstract
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt- This document discusses transport issues that arise within protocols
../data/rfc/rfc3539.txt: for Authentication, Authorization and Accounting (AAA). It also
../data/rfc/rfc3539.txt- provides recommendations on the use of transport by AAA protocols.
../data/rfc/rfc3539.txt- This includes usage of standards-track RFCs as well as experimental
../data/rfc/rfc3539.txt- proposals.
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt-Table of Contents
--
../data/rfc/rfc3539.txt- Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 41
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt-1. Introduction
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt- This document discusses transport issues that arise within protocols
../data/rfc/rfc3539.txt: for Authentication, Authorization and Accounting (AAA). It also
../data/rfc/rfc3539.txt- provides recommendations on the use of transport by AAA protocols.
../data/rfc/rfc3539.txt- This includes usage of standards-track RFCs as well as experimental
../data/rfc/rfc3539.txt- proposals.
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt-1.1. Requirements Language
--
../data/rfc/rfc3539.txt- "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
../data/rfc/rfc3539.txt- described in [RFC2119].
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt-1.2. Terminology
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt: Accounting
../data/rfc/rfc3539.txt- The act of collecting information on resource usage for the
../data/rfc/rfc3539.txt- purpose of trend analysis, auditing, billing, or cost
../data/rfc/rfc3539.txt- allocation.
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt-
--
../data/rfc/rfc3539.txt- forward proxies need to implement AAA client and server
../data/rfc/rfc3539.txt- functionality for the messages that they handle. Store and
../data/rfc/rfc3539.txt- Forward proxies also typically keep state on conversations
../data/rfc/rfc3539.txt- in progress in order to assure delivery of proxied Requests
../data/rfc/rfc3539.txt- and Responses. While store and forward proxies are most
../data/rfc/rfc3539.txt: frequently deployed for accounting, they also can be used
../data/rfc/rfc3539.txt- to implement authentication/authorization policy.
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt- Network-driven transport
../data/rfc/rfc3539.txt- Transport behavior is said to be "network driven" when the
../data/rfc/rfc3539.txt- rate at which messages are sent is limited by the
--
../data/rfc/rfc3539.txt- application, rather than by the size of the congestion window.
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt- For example, let us assume a 48-port NAS with an average session time
../data/rfc/rfc3539.txt- of 20 minutes. This device will, on average, send only 144
../data/rfc/rfc3539.txt- authentication/authorization requests/hour, and an equivalent number
../data/rfc/rfc3539.txt: of accounting requests. This represents an average inter-packet
../data/rfc/rfc3539.txt- spacing of 25 seconds, which is much larger than the Round Trip Time
../data/rfc/rfc3539.txt- (RTT) in most networks.
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt-
--
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt- Even on much larger NAS devices, the inter-packet spacing is often
../data/rfc/rfc3539.txt- larger than the RTT. For example, consider a 2048-port NAS with an
../data/rfc/rfc3539.txt- average session time of 10 minutes. It will on average send 3.4
../data/rfc/rfc3539.txt- authentication/authorization requests/second, and an equivalent
../data/rfc/rfc3539.txt: number of accounting requests. This translates to an average inter-
../data/rfc/rfc3539.txt- packet spacing of 293 ms.
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt- However, even where transport behavior is largely application-driven,
../data/rfc/rfc3539.txt- periods of network-driven behavior can occur. For example, after a
../data/rfc/rfc3539.txt: NAS reboot, previously stored accounting records may be sent to the
../data/rfc/rfc3539.txt: accounting server in rapid succession. Similarly, after recovery
../data/rfc/rfc3539.txt- from a power failure, users may respond with a large number of
../data/rfc/rfc3539.txt- simultaneous logins. In both cases, AAA messages may be generated
../data/rfc/rfc3539.txt- more quickly than the network will allow them to be sent, and a queue
../data/rfc/rfc3539.txt- will build up.
../data/rfc/rfc3539.txt-
--
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt- Let us consider what happens when 10,000 48-ports NASes, each with an
../data/rfc/rfc3539.txt- average session time of 20 minutes, are configured with the same AAA
../data/rfc/rfc3539.txt- agent or server. The unfortunate proxy or server would receive 400
../data/rfc/rfc3539.txt- authentication/authorization requests/second and an equivalent number
../data/rfc/rfc3539.txt: of accounting requests. For 1000 octet requests, this would generate
../data/rfc/rfc3539.txt- 6.4 Mbps of incoming traffic at the AAA agent or server.
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt- While this transaction load is within the capabilities of the fastest
../data/rfc/rfc3539.txt- AAA agents and servers, implementations exist that cannot handle such
../data/rfc/rfc3539.txt- a high load. Thus high queuing delays and/or dropped packets may be
--
../data/rfc/rfc3539.txt- can be reduced by combining multiple AAA messages within a single
../data/rfc/rfc3539.txt- packet.
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt- Where AAA runs over TCP and transport behavior is network-driven,
../data/rfc/rfc3539.txt- such as after a reboot when many users login simultaneously, or many
../data/rfc/rfc3539.txt: stored accounting records need to be sent, the Nagle algorithm will
../data/rfc/rfc3539.txt- result in "transport layer batching" of AAA messages. While this
../data/rfc/rfc3539.txt- does not reduce the work required by the application in parsing
../data/rfc/rfc3539.txt- packets and responding to the messages, it does reduce the number of
../data/rfc/rfc3539.txt- packets processed by routers along the path. The Nagle algorithm is
../data/rfc/rfc3539.txt- not used with SCTP.
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt- Where AAA transport is application-driven, the NAS will typically
../data/rfc/rfc3539.txt- receive a reply from the home server prior to having another request
../data/rfc/rfc3539.txt: to send. This implies, for example, that accounting requests will
../data/rfc/rfc3539.txt- typically be sent individually rather than being batched by the
../data/rfc/rfc3539.txt- transport layer. As a result, within the application-driven regime,
../data/rfc/rfc3539.txt- the Nagle algorithm [RFC896] is ineffective.
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt-2.4. Multiple Connections
--
../data/rfc/rfc3539.txt- those sent on the failed connection. As a result, AAA agents and
../data/rfc/rfc3539.txt- servers MUST be prepared to handle duplicates, and MUST assume that
../data/rfc/rfc3539.txt- duplicates can arrive on any connection.
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt- For example, in billing, it is necessary to be able to weed out
../data/rfc/rfc3539.txt: duplicate accounting records, based on the accounting session-id,
../data/rfc/rfc3539.txt- event-timestamp and NAS identification information. Where
../data/rfc/rfc3539.txt- authentication requests are always idempotent, the resultant
../data/rfc/rfc3539.txt- duplicate responses from multiple servers will presumably be
../data/rfc/rfc3539.txt- identical, so that little harm will result.
../data/rfc/rfc3539.txt-
--
../data/rfc/rfc3539.txt-Aboba & Wood Standards Track [Page 26]
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt-RFC 3539 AAA Transport Profile June 2003
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt- [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
../data/rfc/rfc3539.txt- 2914, September 2000.
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt- [RFC2975] Aboba, B., Arkko, J. and D. Harrington, "Introduction to
../data/rfc/rfc3539.txt: Accounting Management", RFC 2975, June 2000.
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt- [RFC3390] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's
../data/rfc/rfc3539.txt- Initial Window", RFC 3390, October 2002.
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt- [Congest] Jacobson, V., "Congestion Avoidance and Control", Computer
--
../data/rfc/rfc3539.txt-Appendix B - AAA Agents
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt- As described in [RFC2865] and [RFC2607], AAA agents have become
../data/rfc/rfc3539.txt- popular in order to support services such as roaming and shared use
../data/rfc/rfc3539.txt- networks. Such agents are used both for
../data/rfc/rfc3539.txt: authentication/authorization, as well as accounting [RFC2975].
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt- AAA agents include:
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt- Relays
../data/rfc/rfc3539.txt- Proxies
--
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt-B.3 Store and Forward Proxies
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt- With a store and forward proxy, the proxy may send a reply to the NAS
../data/rfc/rfc3539.txt- prior to forwarding the request to the server. While store and
../data/rfc/rfc3539.txt: forward proxies are most frequently deployed for accounting
../data/rfc/rfc3539.txt- [RFC2975], they also can be used to implement
../data/rfc/rfc3539.txt- authentication/authorization policy, as described in [RFC2607].
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt- As noted in [RFC2975], store and forward proxies can have a negative
../data/rfc/rfc3539.txt: effect on accounting reliability. By sending a reply to the NAS
../data/rfc/rfc3539.txt: without receiving one from the accounting server, store and forward
../data/rfc/rfc3539.txt: proxies fool the NAS into thinking that the accounting request had
../data/rfc/rfc3539.txt: been accepted by the accounting server when this is not the case. As
../data/rfc/rfc3539.txt: a result, the NAS can delete the accounting packet from non-volatile
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt-Aboba & Wood Standards Track [Page 36]
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt-RFC 3539 AAA Transport Profile June 2003
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt: storage before it has been accepted by the accounting server. That
../data/rfc/rfc3539.txt: leaves the proxy responsible for delivering accounting packets. If
../data/rfc/rfc3539.txt- the proxy involves moving parts (e.g. a disk drive) while the NAS
../data/rfc/rfc3539.txt- does not, overall system reliability can be reduced. As a result,
../data/rfc/rfc3539.txt- store and forward proxies SHOULD NOT be used.
../data/rfc/rfc3539.txt-
../data/rfc/rfc3539.txt- The sequence of events is as follows:
--
../data/rfc/rfc4058.txt- 2. Requirements Notation ...........................................3
../data/rfc/rfc4058.txt- 3. Terminology .....................................................4
../data/rfc/rfc4058.txt- 4. Requirements ....................................................4
../data/rfc/rfc4058.txt- 4.1. Authentication .............................................4
../data/rfc/rfc4058.txt- 4.1.1. Authentication of Client ............................4
../data/rfc/rfc4058.txt: 4.1.2. Authorization, Accounting, and Access Control .......6
../data/rfc/rfc4058.txt- 4.1.3. Authentication Backend ..............................7
../data/rfc/rfc4058.txt- 4.1.4. Identifiers .........................................7
../data/rfc/rfc4058.txt- 4.2. IP Address Assignment ......................................7
../data/rfc/rfc4058.txt- 4.3. EAP Lower Layer Requirements ...............................7
../data/rfc/rfc4058.txt- 4.4. PAA-to-EP Protocol .........................................8
--
../data/rfc/rfc4058.txt- where the network is vulnerable to man-in-the-middle attacks. While
../data/rfc/rfc4058.txt- PANA MUST provide such a capability, its utility relies on the use of
../data/rfc/rfc4058.txt- an authentication method that can generate keys for cryptographic
../data/rfc/rfc4058.txt- computations on PaC and PAA.
../data/rfc/rfc4058.txt-
../data/rfc/rfc4058.txt:4.1.2. Authorization, Accounting, and Access Control
../data/rfc/rfc4058.txt-
../data/rfc/rfc4058.txt- After a device is authenticated by using PANA, it MUST be authorized
../data/rfc/rfc4058.txt- for "network access." That is, the core requirement of PANA is to
../data/rfc/rfc4058.txt- verify the authorization of a PaC so that PaC's device may send and
../data/rfc/rfc4058.txt- receive any IP packets. It may also be possible to provide finer
--
../data/rfc/rfc4058.txt- network, PaC and EPs should have the required IPsec SA in place.
../data/rfc/rfc4058.txt- Generating the IPsec SAs based on EAP keys is outside the scope of
../data/rfc/rfc4058.txt- PANA protocol. This transformation MUST be handled by a separate
../data/rfc/rfc4058.txt- secure association protocol (see section 4.1.1).
../data/rfc/rfc4058.txt-
../data/rfc/rfc4058.txt: Carrying accounting data is outside the scope of PANA.
../data/rfc/rfc4058.txt-
../data/rfc/rfc4058.txt-
../data/rfc/rfc4058.txt-
../data/rfc/rfc4058.txt-
../data/rfc/rfc4058.txt-Yegin, et al. Informational [Page 6]
--
../data/rfc/rfc4058.txt- PANA payload, or implicitly as the source of the PANA message, or
../data/rfc/rfc4058.txt- both. Multi-access networks also require use of a cryptographic
../data/rfc/rfc4058.txt- protection along with DI filtering to prevent unauthorized access
../data/rfc/rfc4058.txt- [RFC4016]. The keying material required by the cryptographic methods
../data/rfc/rfc4058.txt- needs to be indexed by the DI. As described in section 4.1.2, the
../data/rfc/rfc4058.txt: binding between DI and PaCI is used for access control and accounting
../data/rfc/rfc4058.txt- in the network.
../data/rfc/rfc4058.txt-
../data/rfc/rfc4058.txt-4.2. IP Address Assignment
../data/rfc/rfc4058.txt-
../data/rfc/rfc4058.txt- Assigning an IP address to the client is outside the scope of PANA.
--
../data/rfc/rfc5030.txt- Thus, the Mobile IP group developed a set of guidelines and
../data/rfc/rfc5030.txt- requirements from the Mobile IP standpoint [RFC2977] specifically for
../data/rfc/rfc5030.txt- such a successor (which turned out to be Diameter). These
../data/rfc/rfc5030.txt- requirements led to the development of a specification for using
../data/rfc/rfc5030.txt- Diameter in Mobile IPv4 bootstrapping [RFC4004]. The requirements
../data/rfc/rfc5030.txt: for Mobile IP Authentication, Authorization, and Accounting [RFC2977]
../data/rfc/rfc5030.txt- were standardized after the standardization of RADIUS [RFC2865].
../data/rfc/rfc5030.txt-
../data/rfc/rfc5030.txt- Thus, it is obvious that RADIUS does not and cannot meet all the
../data/rfc/rfc5030.txt- requirements listed in [RFC2977] without undergoing an extensive
../data/rfc/rfc5030.txt- design change. Consequently, within IETF no RADIUS attributes have
--
../data/rfc/rfc5030.txt-
../data/rfc/rfc5030.txt- [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
../data/rfc/rfc5030.txt- "Remote Authentication Dial In User Service (RADIUS)",
../data/rfc/rfc5030.txt- RFC 2865, June 2000.
../data/rfc/rfc5030.txt-
../data/rfc/rfc5030.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc5030.txt-
../data/rfc/rfc5030.txt-
../data/rfc/rfc5030.txt-
../data/rfc/rfc5030.txt-
../data/rfc/rfc5030.txt-
../data/rfc/rfc5030.txt-Nakhjiri, et al. Informational [Page 6]
../data/rfc/rfc5030.txt-
../data/rfc/rfc5030.txt-RFC 5030 Mobile IPv4 RADIUS Requirements October 2007
../data/rfc/rfc5030.txt-
../data/rfc/rfc5030.txt-
../data/rfc/rfc5030.txt: [RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting
../data/rfc/rfc5030.txt- Modifications for Tunnel Protocol Support", RFC 2867,
../data/rfc/rfc5030.txt- June 2000.
../data/rfc/rfc5030.txt-
../data/rfc/rfc5030.txt- [RFC2977] Glass, S., Hiller, T., Jacobs, S., and C. Perkins, "Mobile
../data/rfc/rfc5030.txt: IP Authentication, Authorization, and Accounting
../data/rfc/rfc5030.txt- Requirements", RFC 2977, October 2000.
../data/rfc/rfc5030.txt-
../data/rfc/rfc5030.txt- [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
../data/rfc/rfc5030.txt- August 2002.
../data/rfc/rfc5030.txt-
../data/rfc/rfc5030.txt- [RFC3957] Perkins, C. and P. Calhoun, "Authentication,
../data/rfc/rfc5030.txt: Authorization, and Accounting (AAA) Registration Keys for
../data/rfc/rfc5030.txt- Mobile IPv4", RFC 3957, March 2005.
../data/rfc/rfc5030.txt-
../data/rfc/rfc5030.txt- [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and
../data/rfc/rfc5030.txt- P. McCann, "Diameter Mobile IPv4 Application", RFC 4004,
../data/rfc/rfc5030.txt- August 2005.
--
../data/rfc/rfc5030.txt- [RFC4721] Perkins, C., Calhoun, P., and J. Bharatia, "Mobile IPv4
../data/rfc/rfc5030.txt- Challenge/Response Extensions (Revised)", RFC 4721,
../data/rfc/rfc5030.txt- January 2007.
../data/rfc/rfc5030.txt-
../data/rfc/rfc5030.txt- [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
../data/rfc/rfc5030.txt: Authorization, and Accounting (AAA) Key Management",
../data/rfc/rfc5030.txt- BCP 132, RFC 4962, July 2007.
../data/rfc/rfc5030.txt-
../data/rfc/rfc5030.txt-8.2. Informative References
../data/rfc/rfc5030.txt-
../data/rfc/rfc5030.txt- [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
--
../data/rfc/rfc3234.txt-2.12. Gatekeepers/ session control boxes
../data/rfc/rfc3234.txt-
../data/rfc/rfc3234.txt- Particularly with the rise of IP Telephony, the need to create and
../data/rfc/rfc3234.txt- manage sessions other than TCP connections has arisen. In a
../data/rfc/rfc3234.txt- multimedia environment that has to deal with name lookup,
../data/rfc/rfc3234.txt: authentication, authorization, accounting, firewall traversal, and
../data/rfc/rfc3234.txt- sometimes media conversion, the establishment and control of a
../data/rfc/rfc3234.txt- session by a third-party box seems to be the inevitable solution.
../data/rfc/rfc3234.txt- Examples include H.323 gatekeepers [H323], SIP servers [RFC 2543] and
../data/rfc/rfc3234.txt- MEGACO controllers [RFC 3015].
../data/rfc/rfc3234.txt-
--
../data/rfc/rfc3234.txt- particular impact on the data stream.
../data/rfc/rfc3234.txt-
../data/rfc/rfc3234.txt- Additionally, content caches and content distribution mechanisms
../data/rfc/rfc3234.txt- raise the issue of access control for content that is subject to
../data/rfc/rfc3234.txt- copyright or other rights. Distributed authentication, authorisation
../data/rfc/rfc3234.txt: and accounting are required.
../data/rfc/rfc3234.txt-
../data/rfc/rfc3234.txt-6. Acknowledgements
../data/rfc/rfc3234.txt-
../data/rfc/rfc3234.txt- Steve Bellovin, Jon Crowcroft, Steve Deering, Patrik Faltstrom,
../data/rfc/rfc3234.txt- Henning Schulzrinne, and Lixia Zhang all gave valuable feedback on
--
../data/rfc/rfc4105.txt- over how traffic demands are routed over a network topology and
../data/rfc/rfc4105.txt- utilize a network's resources.
../data/rfc/rfc4105.txt-
../data/rfc/rfc4105.txt- Note also that TE LSPs allow measuring traffic matrix in a simple and
../data/rfc/rfc4105.txt- scalable manner. The aggregated traffic rate between two LSRs is
../data/rfc/rfc4105.txt: easily measured by accounting of traffic sent onto a TE LSP
../data/rfc/rfc4105.txt- provisioned between the two LSRs in question.
../data/rfc/rfc4105.txt-
../data/rfc/rfc4105.txt-
../data/rfc/rfc4105.txt-
../data/rfc/rfc4105.txt-
--
../data/rfc/rfc4657.txt- requests as set forth in Section 5.1.8.
../data/rfc/rfc4657.txt-
../data/rfc/rfc4657.txt- The path computation request message MUST support TE LSP path
../data/rfc/rfc4657.txt- reoptimization and the inclusion of a previously computed path. This
../data/rfc/rfc4657.txt- will help ensure optimal routing of a reoptimized path, since it will
../data/rfc/rfc4657.txt: allow the PCE to avoid double bandwidth accounting and help reduce
../data/rfc/rfc4657.txt- blocking issues.
../data/rfc/rfc4657.txt-
../data/rfc/rfc4657.txt-6. Security Considerations
../data/rfc/rfc4657.txt-
../data/rfc/rfc4657.txt- Key management MUST be provided by the PCECP to provide for the
--
../data/rfc/rfc4657.txt- Extensions to RSVP for LSP Tunnels", RFC 3209,
../data/rfc/rfc4657.txt- December 2001.
../data/rfc/rfc4657.txt-
../data/rfc/rfc4657.txt- [RFC3127] Mitton, D., St.Johns, M., Barkley, S., Nelson,
../data/rfc/rfc4657.txt- D., Patil, B., Stevens, M., and B. Wolff,
../data/rfc/rfc4657.txt: "Authentication, Authorization, and Accounting:
../data/rfc/rfc4657.txt- Protocol Evaluation", RFC 3127, June 2001.
../data/rfc/rfc4657.txt-
../data/rfc/rfc4657.txt-
../data/rfc/rfc4657.txt-
../data/rfc/rfc4657.txt-
--
../data/rfc/rfc6241.txt- NETCONF session programmatically from within NETCONF if one knows the
../data/rfc/rfc6241.txt- session identifier of the offending session. The other possible way
../data/rfc/rfc6241.txt- to break a lock is to provide a function within the device's native
../data/rfc/rfc6241.txt- user interface. These two mechanisms suffer from a race condition
../data/rfc/rfc6241.txt- that could be ameliorated by removing the offending user from an
../data/rfc/rfc6241.txt: Authentication, Authorization, and Accounting (AAA) server. However,
../data/rfc/rfc6241.txt- such a solution is not useful in all deployment scenarios, such as
../data/rfc/rfc6241.txt- those where SSH public/private key pairs are used.
../data/rfc/rfc6241.txt-
../data/rfc/rfc6241.txt-10. IANA Considerations
../data/rfc/rfc6241.txt-
--
../data/rfc/rfc3141.txt- Copyright (C) The Internet Society (2001). All Rights Reserved.
../data/rfc/rfc3141.txt-
../data/rfc/rfc3141.txt-Abstract
../data/rfc/rfc3141.txt-
../data/rfc/rfc3141.txt- This memo specifies cdma2000 wireless data AAA (Authentication,
../data/rfc/rfc3141.txt: Authorization, Accounting) requirements associated with third
../data/rfc/rfc3141.txt- generation wireless architecture that supports roaming among service
../data/rfc/rfc3141.txt- providers for traditional PPP and Mobile IP services.
../data/rfc/rfc3141.txt-
../data/rfc/rfc3141.txt-
../data/rfc/rfc3141.txt-
--
../data/rfc/rfc3141.txt- home ISP, or private network.
../data/rfc/rfc3141.txt- o Support IP Security on the Mobile IP tunnel between Foreign
../data/rfc/rfc3141.txt- Agent and Home Agent, in order to avoid the overhead of a
../data/rfc/rfc3141.txt- voluntary tunnel on the radio interface.
../data/rfc/rfc3141.txt-
../data/rfc/rfc3141.txt: o Provide robust authentication, authorization and accounting
../data/rfc/rfc3141.txt- services (AAA):
../data/rfc/rfc3141.txt-
../data/rfc/rfc3141.txt- o Provide separation of airlink resource AAA services and data
../data/rfc/rfc3141.txt- resource AAA services.
../data/rfc/rfc3141.txt- o Authenticate and authorize a mobile based on an IMSI and an
--
../data/rfc/rfc3141.txt-2.1. PDSN
../data/rfc/rfc3141.txt-
../data/rfc/rfc3141.txt- o Acts as a Foreign Agent;
../data/rfc/rfc3141.txt- o Establish, maintain, and terminate link layer to the mobile
../data/rfc/rfc3141.txt- client;
../data/rfc/rfc3141.txt: o Initiate the authentication, authorization and accounting for
../data/rfc/rfc3141.txt- the mobile client;
../data/rfc/rfc3141.txt- o Optionally, securely tunnel using IP security to the Home
../data/rfc/rfc3141.txt- Agent;
../data/rfc/rfc3141.txt- o Receives service parameters from AAA for mobile client;
../data/rfc/rfc3141.txt: o Collect usage data for accounting purposes to be relayed to
../data/rfc/rfc3141.txt- AAA;
../data/rfc/rfc3141.txt- o Routes packets to external packet data networks or to the HA in
../data/rfc/rfc3141.txt- the case of reverse tunneling;
../data/rfc/rfc3141.txt- o Maps home address and Home Agent address to a unique link layer
../data/rfc/rfc3141.txt- identifier used to communicate with Radio Network.
../data/rfc/rfc3141.txt-
../data/rfc/rfc3141.txt:2.2. Authentication, Authorization, and Accounting Server
../data/rfc/rfc3141.txt-
../data/rfc/rfc3141.txt- o Interact with the Foreign Agent and other AAA servers to
../data/rfc/rfc3141.txt: authorize, authenticate and perform accounting for the mobile
../data/rfc/rfc3141.txt- client;
../data/rfc/rfc3141.txt- o Provides mechanism to support security association between
../data/rfc/rfc3141.txt- PDSN/FA and HA and between the MN and PDSN/FA;
../data/rfc/rfc3141.txt- o For dynamic Home Agent assignment, dynamically identify an HA
../data/rfc/rfc3141.txt- and assign a MN on that HA, and provide the security
--
../data/rfc/rfc3141.txt- capability to modify certain parts of AAA messages whereby
../data/rfc/rfc3141.txt- to operate to in non-proxy or proxy environments.
../data/rfc/rfc3141.txt- o Provide message integrity and identity authentication on a
../data/rfc/rfc3141.txt- per hop (AAA node) basis.
../data/rfc/rfc3141.txt- o Support replay protection and optional non-repudiation
../data/rfc/rfc3141.txt: capabilities for all authorization and accounting messages.
../data/rfc/rfc3141.txt: The AAA protocol must provide the capability for accounting
../data/rfc/rfc3141.txt- messages to be matched with prior authorization messages.
../data/rfc/rfc3141.txt: o Support accounting via both bilateral arrangements and via
../data/rfc/rfc3141.txt: broker AAA servers providing accounting clearinghouse and
../data/rfc/rfc3141.txt- reconciliation between serving and home networks. There is
../data/rfc/rfc3141.txt- an explicit agreement that if the private network or home
../data/rfc/rfc3141.txt- ISP authenticates the mobile station requesting service,
../data/rfc/rfc3141.txt- then the private network or home ISP network also agrees to
../data/rfc/rfc3141.txt- reconcile charges with the home service provider or broker.
../data/rfc/rfc3141.txt: Real time accounting must be supported.
../data/rfc/rfc3141.txt- o Provides security between AAA servers, and between AAA
../data/rfc/rfc3141.txt- server and PDSN or HA via IP security.
../data/rfc/rfc3141.txt-
../data/rfc/rfc3141.txt-3.2. Mobile IP Specific Requirements and AAA
../data/rfc/rfc3141.txt-
--
../data/rfc/rfc4152.txt- o Handle logistics (movement of circuit cards, along with the serial
../data/rfc/rfc4152.txt- number)
../data/rfc/rfc4152.txt-
../data/rfc/rfc4152.txt- o Provision equipment
../data/rfc/rfc4152.txt-
../data/rfc/rfc4152.txt: o Maintain asset records (accounting information)
../data/rfc/rfc4152.txt-
../data/rfc/rfc4152.txt- The goal of the CLEI namespace is to ensure the stability and
../data/rfc/rfc4152.txt- uniqueness of the names of various (specific) items that are used
../data/rfc/rfc4152.txt- within the messages exchanged between equipment of the global
../data/rfc/rfc4152.txt- telecommunications network.
--
../data/rfc/rfc3690.txt- PSTN/Internet boundaries. Absence of a mapping means that the
../data/rfc/rfc3690.txt- signaling reverts to a default service (presumably one attributed
../data/rfc/rfc3690.txt- to the general public).
../data/rfc/rfc3690.txt-
../data/rfc/rfc3690.txt- 4) Application layer IP telephony capabilities MUST NOT preclude the
../data/rfc/rfc3690.txt: ability to do application layer accounting.
../data/rfc/rfc3690.txt-
../data/rfc/rfc3690.txt: Accounting is a useful feature in support of billing and tracking
../data/rfc/rfc3690.txt- down abuse of service. If specific solutions or protocols in
../data/rfc/rfc3690.txt: support of ETS require accounting, then this will be articulated
../data/rfc/rfc3690.txt- in future document(s).
../data/rfc/rfc3690.txt-
../data/rfc/rfc3690.txt- 5) Application layer mechanisms in gateways and stateful proxies that
../data/rfc/rfc3690.txt- are specifically in place to recognize ETS type labels MUST be
../data/rfc/rfc3690.txt- able to support "best available" service (this will probably be
--
../data/rfc/rfc1639.txt- LPSV commands (500, 501). An additional negative completion reply
../data/rfc/rfc1639.txt- code is needed to distinguish the case where a host supports the LPRT
../data/rfc/rfc1639.txt- or LPSV command, but does not support the address family specified.
../data/rfc/rfc1639.txt-
../data/rfc/rfc1639.txt- Of the FTP function groupings defined for reply codes (syntax,
../data/rfc/rfc1639.txt: information, connections, authentication and accounting, and file
../data/rfc/rfc1639.txt- system), "connections" seems the most logical choice; thus, an
../data/rfc/rfc1639.txt- additional negative command completion reply code, 521 is added, with
../data/rfc/rfc1639.txt- the following suggested textual message:
../data/rfc/rfc1639.txt-
../data/rfc/rfc1639.txt- 521 Supported address families are (af1, af2, ..., afn)
--
../data/rfc/rfc8979.txt- Section 8.2.2 of [RFC8300], identifier values SHOULD be
../data/rfc/rfc8979.txt- obfuscated.
../data/rfc/rfc8979.txt-
../data/rfc/rfc8979.txt- The Subscriber Identifier Context Header is used by SFs to enforce
../data/rfc/rfc8979.txt- per-subscriber policies (e.g., resource quota, customized filtering
../data/rfc/rfc8979.txt: profile, accounting). To that aim, network operators may rely on
../data/rfc/rfc8979.txt- identifiers that are generated from those used in legacy deployments
../data/rfc/rfc8979.txt- (e.g., Section 3.3 of [CASE-MOBILITY]). Alternatively, network
../data/rfc/rfc8979.txt- operators may use identifiers that are associated with customized
../data/rfc/rfc8979.txt- policy profiles that are preconfigured on SFs using an out-of-band
../data/rfc/rfc8979.txt- mechanism. Such a mechanism can be used to rotate the identifiers,
--
../data/rfc/rfc2000.txt-
../data/rfc/rfc2000.txt- 2060 - Internet Message Access Protocol - Version 4rev1
../data/rfc/rfc2000.txt-
../data/rfc/rfc2000.txt- A Proposed Standard protocol.
../data/rfc/rfc2000.txt-
../data/rfc/rfc2000.txt: 2059 - RADIUS Accounting
../data/rfc/rfc2000.txt-
../data/rfc/rfc2000.txt- This is an information document and does not specify any
../data/rfc/rfc2000.txt- level of standard.
../data/rfc/rfc2000.txt-
../data/rfc/rfc2000.txt- 2058 - Remote Authentication Dial In User Service (RADIUS)
--
../data/rfc/rfc1135.txt-
../data/rfc/rfc1135.txt- Machalow, R., "Security for Lotus Files", Computers in Libraries,
../data/rfc/rfc1135.txt- Vol. 9, No. 2, Pg. 19, 1 February 1989.
../data/rfc/rfc1135.txt-
../data/rfc/rfc1135.txt- Maher, J., and J. Hicks, "Computer Viruses: Controller's Nightmare",
../data/rfc/rfc1135.txt: Management Accounting, Vol. 71, No. 4, Pg. 44, 1 October 1989.
../data/rfc/rfc1135.txt-
../data/rfc/rfc1135.txt- Markoff, J., "Author of Computer 'Virus' is Son of U.S. Electronic
../data/rfc/rfc1135.txt- Security Expert", Pgs. A1, A7, The New York Times, 5 November 1988.
../data/rfc/rfc1135.txt-
../data/rfc/rfc1135.txt- Markoff, J., "Computer Experts Say Virus Carried No Hidden Dangers",
--
../data/rfc/rfc1135.txt- United States Congress Senate Committee on the Judiciary, "The
../data/rfc/rfc1135.txt- Computer Fraud and Abuse Act of 1986, Report Together with Additional
../data/rfc/rfc1135.txt- Views", Ninety-ninth Congress, Second Session, Washington, D.C., 3
../data/rfc/rfc1135.txt- September 1986.
../data/rfc/rfc1135.txt-
../data/rfc/rfc1135.txt: United States General Accounting Office, "Computer Security",
../data/rfc/rfc1135.txt- GAO/IMTEC-89-57, June 1989.
../data/rfc/rfc1135.txt-
../data/rfc/rfc1135.txt- United States of America, "Computer Security Act of 1987", G.P.O.
../data/rfc/rfc1135.txt- Distributor, Washington D.C., 1988.
../data/rfc/rfc1135.txt-
--
../data/rfc/rfc1545.txt- errors in the PORT and PASV commands are appropriate for the LPRT and
../data/rfc/rfc1545.txt- LPSV commands (500, 501). An additional negative completion reply
../data/rfc/rfc1545.txt- code is needed to distinguish the case where a host supports the LPRT
../data/rfc/rfc1545.txt- or LPSV command, but does not support the address family specified.
../data/rfc/rfc1545.txt- Of the FTP function groupings currently defined for reply codes
../data/rfc/rfc1545.txt: (syntax, information, connections, authentication and accounting, and
../data/rfc/rfc1545.txt- file system), "connections" seems the most logical choice; thus, an
../data/rfc/rfc1545.txt- additional negative command completion reply code, 521 is added, with
../data/rfc/rfc1545.txt- the following suggested textual message:
../data/rfc/rfc1545.txt-
../data/rfc/rfc1545.txt- 521 Supported address families are (af1, af2, ..., afn)
--
../data/rfc/rfc4433.txt- Redirected HA: If the registration is rejected with error code
../data/rfc/rfc4433.txt- REDIRECT-HA-REQ, the HA being referred to is
../data/rfc/rfc4433.txt- specified in a new extension (Redirected HA
../data/rfc/rfc4433.txt- Extension).
../data/rfc/rfc4433.txt-
../data/rfc/rfc4433.txt: AAA server: Authentication, Authorization, and Accounting
../data/rfc/rfc4433.txt- Server.
../data/rfc/rfc4433.txt-
../data/rfc/rfc4433.txt- DNS: Domain Name System.
../data/rfc/rfc4433.txt-
../data/rfc/rfc4433.txt- DHCP: Dynamic Host Configuration Protocol.
--
../data/rfc/rfc4433.txt-
../data/rfc/rfc4433.txt- [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
../data/rfc/rfc4433.txt- Levels", BCP 14, RFC 2119, March 1997.
../data/rfc/rfc4433.txt-
../data/rfc/rfc4433.txt- [7] Perkins, C. and P. Calhoun, "Authentication, Authorization, and
../data/rfc/rfc4433.txt: Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957,
../data/rfc/rfc4433.txt- March 2005.
../data/rfc/rfc4433.txt-
../data/rfc/rfc4433.txt-
../data/rfc/rfc4433.txt-
../data/rfc/rfc4433.txt-
--
../data/rfc/rfc4071.txt-
../data/rfc/rfc4071.txt-RFC 4071 Structure of IASA April 2005
../data/rfc/rfc4071.txt-
../data/rfc/rfc4071.txt-
../data/rfc/rfc4071.txt- 5. IASA Funding . . . . . . . . . . . . . . . . . . . . . . . . . 14
../data/rfc/rfc4071.txt: 5.1. Cost Center Accounting . . . . . . . . . . . . . . . . . 14
../data/rfc/rfc4071.txt- 5.2. IETF Meeting Revenues . . . . . . . . . . . . . . . . . 14
../data/rfc/rfc4071.txt- 5.3. Designated Donations, Monetary and In-Kind . . . . . . . 14
../data/rfc/rfc4071.txt- 5.4. Other ISOC Support . . . . . . . . . . . . . . . . . . . 15
../data/rfc/rfc4071.txt- 5.5. IASA Expenses . . . . . . . . . . . . . . . . . . . . . 15
../data/rfc/rfc4071.txt- 5.6. Operating Reserve . . . . . . . . . . . . . . . . . . . 15
--
../data/rfc/rfc4071.txt-
../data/rfc/rfc4071.txt- 5. Once funds or in-kind donations have been credited to the IASA
../data/rfc/rfc4071.txt- accounts, they shall be irrevocably allocated to the support of
../data/rfc/rfc4071.txt- the IETF.
../data/rfc/rfc4071.txt-
../data/rfc/rfc4071.txt: 6. There shall be a detailed public accounting to separately
../data/rfc/rfc4071.txt- identify all funds available to and all expenditures relating to
../data/rfc/rfc4071.txt- the IETF and to the IASA, including any donations, of funds or in
../data/rfc/rfc4071.txt- kind, received by ISOC for IETF-related activities. In-kind
../data/rfc/rfc4071.txt- donations shall only be accepted at the direction of the IAD and
../data/rfc/rfc4071.txt- IAOC.
--
../data/rfc/rfc4071.txt- equivalent instruments with outside organizations, and for providing
../data/rfc/rfc4071.txt- any coordination necessary to make sure that the IETF administrative
../data/rfc/rfc4071.txt- support functions are covered properly. All functions, whether
../data/rfc/rfc4071.txt- contracted to outside organizations or performed internally within
../data/rfc/rfc4071.txt- the IASA, must be clearly specified and documented with well-defined
../data/rfc/rfc4071.txt: deliverables, service level agreements, and transparent accounting
../data/rfc/rfc4071.txt- for the cost of such functions.
../data/rfc/rfc4071.txt-
../data/rfc/rfc4071.txt- The IASA is responsible for managing all intellectual property rights
../data/rfc/rfc4071.txt- (IPR), including but not limited to trademarks, and copyrights that
../data/rfc/rfc4071.txt- belong to the IETF. The IASA is also responsible for managing the
--
../data/rfc/rfc4071.txt- The IASA is responsible for undertaking any and all required actions
../data/rfc/rfc4071.txt- on behalf of the IETF to obtain, protect, and manage the rights that
../data/rfc/rfc4071.txt- the IETF needs to carry out its work.
../data/rfc/rfc4071.txt-
../data/rfc/rfc4071.txt- If the IASA cannot comply with the procedures described in this
../data/rfc/rfc4071.txt: document for legal, accounting, or practical reasons, the IAOC shall
../data/rfc/rfc4071.txt- report that fact to the community, along with the variant procedure
../data/rfc/rfc4071.txt- that the IAOC intends to follow. If the problem is a long-term one,
../data/rfc/rfc4071.txt- the IAOC shall ask the IETF to update this document to reflect the
../data/rfc/rfc4071.txt- changed procedure.
../data/rfc/rfc4071.txt-
--
../data/rfc/rfc4071.txt-
../data/rfc/rfc4071.txt- Note that the goal is to achieve and maintain a viable IETF support
../data/rfc/rfc4071.txt- function based on available funding sources. The IETF community
../data/rfc/rfc4071.txt- expects the IAOC and ISOC to work together to attain that goal.
../data/rfc/rfc4071.txt-
../data/rfc/rfc4071.txt:5.1. Cost Center Accounting
../data/rfc/rfc4071.txt-
../data/rfc/rfc4071.txt- Funds managed by the IASA shall be accounted for in a separate set of
../data/rfc/rfc4071.txt- general ledger accounts within the IASA Cost Center. In the
../data/rfc/rfc4071.txt- remainder of this document, these general ledger accounts are termed
../data/rfc/rfc4071.txt- "IASA accounts". A periodic summary of the IASA accounts shall be
--
../data/rfc/rfc4071.txt-
../data/rfc/rfc4071.txt- The IAOC and ISOC shall agree upon and publish procedures for
../data/rfc/rfc4071.txt- reporting and auditing of these accounts.
../data/rfc/rfc4071.txt-
../data/rfc/rfc4071.txt- Note that ISOC in consultation with the IAOC can decide to structure
../data/rfc/rfc4071.txt: the IASA accounting differently in the future within the constraints
../data/rfc/rfc4071.txt- outlined in Section 7.
../data/rfc/rfc4071.txt-
../data/rfc/rfc4071.txt-5.2. IETF Meeting Revenues
../data/rfc/rfc4071.txt-
../data/rfc/rfc4071.txt- Meeting revenues are an important source of funds for IETF functions.
--
../data/rfc/rfc4071.txt- The dates described above are examples and are subject to change.
../data/rfc/rfc4071.txt- They will most likely be modified each year based on the dates of the
../data/rfc/rfc4071.txt- second and third IETF meetings of that year. They also need to be
../data/rfc/rfc4071.txt- synchronized with the ISOC budgeting process.
../data/rfc/rfc4071.txt-
../data/rfc/rfc4071.txt: The IAD shall provide monthly accountings of expenses and shall
../data/rfc/rfc4071.txt- update expenditures forecasts every quarter. This may require
../data/rfc/rfc4071.txt- adjustment of the IASA budget. If so, the revised budget will need
../data/rfc/rfc4071.txt- to be approved by the IAOC, the ISOC President/CEO and, if necessary,
../data/rfc/rfc4071.txt- the ISOC Board of Trustees.
../data/rfc/rfc4071.txt-
--
../data/rfc/rfc3530.txt- With delegations, a client is able to avoid writing data to the
../data/rfc/rfc3530.txt- server when the CLOSE of a file is serviced. The file close system
../data/rfc/rfc3530.txt- call is the usual point at which the client is notified of a lack of
../data/rfc/rfc3530.txt- stable storage for the modified file data generated by the
../data/rfc/rfc3530.txt- application. At the close, file data is written to the server and
../data/rfc/rfc3530.txt: through normal accounting the server is able to determine if the
../data/rfc/rfc3530.txt- available filesystem space for the data has been exceeded (i.e.,
../data/rfc/rfc3530.txt: server returns NFS4ERR_NOSPC or NFS4ERR_DQUOT). This accounting
../data/rfc/rfc3530.txt- includes quotas. The introduction of delegations requires that a
../data/rfc/rfc3530.txt- alternative method be in place for the same type of communication to
../data/rfc/rfc3530.txt- occur between client and server.
../data/rfc/rfc3530.txt-
../data/rfc/rfc3530.txt- In the delegation response, the server provides either the limit of
--
../data/rfc/rfc1713.txt- when you talk to someuser@some.host, when your mail has to be routed
../data/rfc/rfc1713.txt- through a set to gateways before it reaches the final recipient, when
../data/rfc/rfc1713.txt- you post an article to Usenet and want it propagated all over the
../data/rfc/rfc1713.txt- world. While these may be the most visible uses of DNS, a lot more
../data/rfc/rfc1713.txt- applications rely on this system to operate, e.g., network security,
../data/rfc/rfc1713.txt: monitoring and accounting tools, just to mention a few.
../data/rfc/rfc1713.txt-
../data/rfc/rfc1713.txt- DNS owes much of its success to its distributed administration. Each
../data/rfc/rfc1713.txt- component (called a zone, the same as a domain in most cases), is
../data/rfc/rfc1713.txt- seen as an independent entity, being responsible for what happens
../data/rfc/rfc1713.txt- inside its domain of authority, how and what information changes and
--
../data/rfc/rfc6632.txt- 4.1.5. Application-Layer Data Models ......................41
../data/rfc/rfc6632.txt- 4.1.6. Network Management Infrastructure Data Models ......41
../data/rfc/rfc6632.txt- 4.2. Network Management Data Models - FCAPS View ...............41
../data/rfc/rfc6632.txt- 4.2.1. Fault Management ...................................42
../data/rfc/rfc6632.txt- 4.2.2. Configuration Management ...........................44
../data/rfc/rfc6632.txt: 4.2.3. Accounting Management ..............................45
../data/rfc/rfc6632.txt- 4.2.4. Performance Management .............................46
../data/rfc/rfc6632.txt- 4.2.5. Security Management ................................48
../data/rfc/rfc6632.txt- 5. Security Considerations ........................................49
../data/rfc/rfc6632.txt- 6. Contributors ...................................................51
../data/rfc/rfc6632.txt- 7. Acknowledgements ...............................................52
--
../data/rfc/rfc6632.txt- standardized within the IETF. Section 4.1 focuses on a broader view
../data/rfc/rfc6632.txt- of models classified into categories such as generic and
../data/rfc/rfc6632.txt- infrastructure data models as well as data models matched to
../data/rfc/rfc6632.txt- different layers. Whereas Section 4.2 structures the data models
../data/rfc/rfc6632.txt- following the management application view and maps them to the
../data/rfc/rfc6632.txt: network management tasks fault, configuration, accounting,
../data/rfc/rfc6632.txt- performance, and security management.
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- Appendix A guides the reader for the high-level selection of
../data/rfc/rfc6632.txt- management standards. For this, the section classifies the protocols
../data/rfc/rfc6632.txt- according to high-level criteria, such as push versus pull
--
../data/rfc/rfc6632.txt- ensured. The IPFIX and PSAMP protocols do not define any new
../data/rfc/rfc6632.txt- security mechanisms and rely on the security mechanism of the
../data/rfc/rfc6632.txt- underlying transport protocol, such as TLS [RFC5246] and DTLS
../data/rfc/rfc6632.txt- [RFC6347].
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt: The primary goal of IPFIX is the reporting of the flow accounting for
../data/rfc/rfc6632.txt: flexible flow definitions and usage-based accounting. As described
../data/rfc/rfc6632.txt- in the IPFIX Applicability Statement [RFC5472], there are also other
../data/rfc/rfc6632.txt- applications such as traffic profiling, traffic engineering,
../data/rfc/rfc6632.txt- intrusion detection, and QoS monitoring, that require flow-based
../data/rfc/rfc6632.txt- traffic measurements and can be realized using IPFIX. Furthermore,
../data/rfc/rfc6632.txt-
--
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- "Remote Authentication Dial In User Service (RADIUS)" [RFC2865]
../data/rfc/rfc6632.txt- describes a client/server protocol for carrying authentication,
../data/rfc/rfc6632.txt- authorization, and configuration information between a Network Access
../data/rfc/rfc6632.txt- Server (NAS), which desires to authenticate its links, and a shared
../data/rfc/rfc6632.txt: authentication server. The companion document "Radius Accounting"
../data/rfc/rfc6632.txt: [RFC2866] describes a protocol for carrying accounting information
../data/rfc/rfc6632.txt: between a NAS and a shared accounting server. [RFC2867] adds
../data/rfc/rfc6632.txt: required new RADIUS accounting attributes and new values designed to
../data/rfc/rfc6632.txt- support the provision of tunneling in dial-up networks.
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- The RADIUS protocol is widely used in environments like enterprise
../data/rfc/rfc6632.txt- networks, where a single administrative authority manages the network
../data/rfc/rfc6632.txt- and protects the privacy of user information. RADIUS is deployed in
--
../data/rfc/rfc6632.txt- authenticators. In the context of 802.1X and EAP-based
../data/rfc/rfc6632.txt- authentication, the VSAs described in [RFC2458] have been widely
../data/rfc/rfc6632.txt- accepted by the industry. "RADIUS Extensions" [RFC2869] is another
../data/rfc/rfc6632.txt- important RFC related to EAP use. RFC 2869 describes additional
../data/rfc/rfc6632.txt- attributes for carrying AAA information between a NAS and a shared
../data/rfc/rfc6632.txt: accounting server using RADIUS. It also defines attributes to
../data/rfc/rfc6632.txt- encapsulate EAP message payload.
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- There are different MIB modules defined for multiple purposes to use
../data/rfc/rfc6632.txt- with RADIUS (see Sections 4.2.3 and 4.2.5).
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt-3.6. Diameter Base Protocol (Diameter)
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- Diameter [RFC3588] provides an Authentication, Authorization, and
../data/rfc/rfc6632.txt: Accounting (AAA) framework for applications such as network access or
../data/rfc/rfc6632.txt- IP mobility. Diameter is also intended to work in local AAA and in
../data/rfc/rfc6632.txt- roaming scenarios. Diameter provides an upgrade path for RADIUS but
../data/rfc/rfc6632.txt- is not directly backwards compatible.
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- Diameter is designed to resolve a number of known problems with
--
../data/rfc/rfc6632.txt- nodes. Each application has an IANA-assigned unique identifier,
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- o Support of application layer acknowledgements, failover methods
../data/rfc/rfc6632.txt- and state machines,
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt: o Basic support for user-sessions and accounting,
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- o Better roaming support,
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- o Error notification, and
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- o Easy extensibility.
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- The Diameter protocol is designed to be extensible to support, e.g.,
../data/rfc/rfc6632.txt- proxies, brokers, mobility and roaming, Network Access Servers
../data/rfc/rfc6632.txt: (NASREQ), and Accounting and Resource Management. Diameter
../data/rfc/rfc6632.txt- applications extend the Diameter base protocol by adding new commands
../data/rfc/rfc6632.txt- and/or attributes. Each application is defined by a unique IANA-
../data/rfc/rfc6632.txt- assigned application identifier and can add new command codes and/or
../data/rfc/rfc6632.txt- new mandatory AVPs.
../data/rfc/rfc6632.txt-
--
../data/rfc/rfc6632.txt- published at IETF:
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- o Diameter Base Protocol Application [RFC3588]: Required support
../data/rfc/rfc6632.txt- from all Diameter implementations.
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt: o Diameter Base Accounting Application [RFC3588]: A Diameter
../data/rfc/rfc6632.txt: application using an accounting protocol based on a server-
../data/rfc/rfc6632.txt- directed model with capabilities for real-time delivery of
../data/rfc/rfc6632.txt: accounting information.
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt-Ersue & Claise Informational [Page 32]
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt-RFC 6632 IETF Management Standards June 2012
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- o Diameter Mobile IPv4 Application [RFC4004]: A Diameter application
../data/rfc/rfc6632.txt- that allows a Diameter server to authenticate, authorize, and
../data/rfc/rfc6632.txt: collect accounting information for Mobile IPv4 services rendered
../data/rfc/rfc6632.txt- to a mobile node.
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- o Diameter Network Access Server Application (NASREQ, [RFC4005]): A
../data/rfc/rfc6632.txt- Diameter application used for AAA services in the NAS environment.
../data/rfc/rfc6632.txt-
--
../data/rfc/rfc6632.txt- focuses on a broader view of models classified into categories such
../data/rfc/rfc6632.txt- as generic and infrastructure data models as well as data models
../data/rfc/rfc6632.txt- matched to different layers. The second subsection is structured
../data/rfc/rfc6632.txt- following the management application view and focuses mainly on the
../data/rfc/rfc6632.txt- data models for the network management tasks fault, configuration,
../data/rfc/rfc6632.txt: accounting, performance, and security management (see [FCAPS]).
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- Note that the IETF does not use the FCAPS view as an organizing
../data/rfc/rfc6632.txt- principle for its data models. However, the FCAPS view is used
../data/rfc/rfc6632.txt- widely outside of the IETF for the realization of management tasks
../data/rfc/rfc6632.txt- and applications. Section 4.2 aims to address the FCAPS view to
--
../data/rfc/rfc6632.txt- Cable Modems [RFC4546], or Ethernet [RFC4188] [RFC4318] [RFC4363].
../data/rfc/rfc6632.txt- These so-called transmission data models typically extend the generic
../data/rfc/rfc6632.txt- network interfaces data model with interface type specific
../data/rfc/rfc6632.txt- information. Most of the link-layer data models focus on monitoring
../data/rfc/rfc6632.txt- capabilities that can be used for performance and fault management
../data/rfc/rfc6632.txt: functions and, to some lesser extent, for accounting and security
../data/rfc/rfc6632.txt- management functions. Meanwhile, the IEEE has taken over the
../data/rfc/rfc6632.txt- responsibility to maintain and further develop data models for the
../data/rfc/rfc6632.txt- IEEE 802 family of protocols [RFC4663]. The cable modem industry
../data/rfc/rfc6632.txt- consortium DOCSIS is working with the IETF to publish data models for
../data/rfc/rfc6632.txt- cable modem networks as IETF Standards Track specifications.
--
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt-4.2. Network Management Data Models - FCAPS View
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- This subsection follows the management application view and aims to
../data/rfc/rfc6632.txt- match the data models to network management tasks for fault,
../data/rfc/rfc6632.txt: configuration, accounting, performance, and security management
../data/rfc/rfc6632.txt- ([FCAPS]). As OAM is a general term that refers to a toolset, which
../data/rfc/rfc6632.txt- can be used for fault detection, isolation, and performance
../data/rfc/rfc6632.txt- measurement, aspects of FCAPS in the context of the data path, such
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt-
--
../data/rfc/rfc6632.txt- wireless binding.
../data/rfc/rfc6632.txt- Note: RFC 5833 and RFC 5834 have been published as Informational RFCs
../data/rfc/rfc6632.txt- to provide the basis for future work on a SNMP management of the
../data/rfc/rfc6632.txt- CAPWAP protocol.
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt:4.2.3. Accounting Management
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt: Accounting management collects usage information of network
../data/rfc/rfc6632.txt- resources. Note that the IETF does not define any mechanisms related
../data/rfc/rfc6632.txt- to billing and charging. Many technology-specific MIBs (link layer,
../data/rfc/rfc6632.txt- network layer, transport layer, or application layer) contain
../data/rfc/rfc6632.txt: counters but are not primarily targeted for accounting and,
../data/rfc/rfc6632.txt- therefore, are not included in this section.
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt: "RADIUS Accounting Client MIB for IPv6" [RFC4670] defines RADIUS
../data/rfc/rfc6632.txt: Accounting Client MIB objects that support version-neutral IP
../data/rfc/rfc6632.txt- addressing formats.
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt: "RADIUS Accounting Server MIB for IPv6" [RFC4671] defines RADIUS
../data/rfc/rfc6632.txt: Accounting Server MIB objects that support version-neutral IP
../data/rfc/rfc6632.txt- addressing formats.
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- IPFIX/PSAMP Information Elements:
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- As expressed in Section 2.3, the IPFIX Architecture [RFC5470] defines
../data/rfc/rfc6632.txt- components involved in IP flow measurement and reporting of
../data/rfc/rfc6632.txt- information on IP flows. As such, IPFIX records provide fine-grained
../data/rfc/rfc6632.txt- measurement data for flexible and detailed usage reporting and enable
../data/rfc/rfc6632.txt: usage-based accounting.
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt-Ersue & Claise Informational [Page 45]
--
../data/rfc/rfc6632.txt- Management Framework For Open Systems Interconnection
../data/rfc/rfc6632.txt- (OSI) For CCITT Applications", September 1992,
../data/rfc/rfc6632.txt- <http://www.itu.int/rec/T-REC-X.700-199209-I/en>.
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- [IANA-AAA] Internet Assigned Numbers Authority, "Authentication,
../data/rfc/rfc6632.txt: Authorization, and Accounting (AAA) Parameters",
../data/rfc/rfc6632.txt- February 2012,
../data/rfc/rfc6632.txt- <http://www.iana.org/assignments/aaa-parameters>.
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- [IANA-IPFIX] Internet Assigned Numbers Authority, "IP Flow
../data/rfc/rfc6632.txt- Information Export (IPFIX) Entities", May 2012,
--
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
../data/rfc/rfc6632.txt- "Remote Authentication Dial In User Service
../data/rfc/rfc6632.txt- (RADIUS)", RFC 2865, June 2000.
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- [RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS
../data/rfc/rfc6632.txt: Accounting Modifications for Tunnel Protocol
../data/rfc/rfc6632.txt- Support", RFC 2867, June 2000.
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J.,
../data/rfc/rfc6632.txt- Holdrege, M., and I. Goyret, "RADIUS Attributes for
../data/rfc/rfc6632.txt- Tunnel Protocol Support", RFC 2868, June 2000.
--
../data/rfc/rfc6632.txt- IPv6", RFC 4668, August 2006.
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- [RFC4669] Nelson, D., "RADIUS Authentication Server MIB for
../data/rfc/rfc6632.txt- IPv6", RFC 4669, August 2006.
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt: [RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6",
../data/rfc/rfc6632.txt- RFC 4670, August 2006.
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt: [RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6",
../data/rfc/rfc6632.txt- RFC 4671, August 2006.
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- [RFC4672] De Cnodder, S., Jonnala, N., and M. Chiba, "RADIUS
../data/rfc/rfc6632.txt- Dynamic Authorization Client MIB", RFC 4672,
../data/rfc/rfc6632.txt- September 2006.
--
../data/rfc/rfc6632.txt- Sinnreich, "Session Initiation Protocol Event Package
../data/rfc/rfc6632.txt- for Voice Quality Reporting", RFC 6035,
../data/rfc/rfc6632.txt- November 2010.
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- [RFC6065] Narayan, K., Nelson, D., and R. Presuhn, "Using
../data/rfc/rfc6632.txt: Authentication, Authorization, and Accounting
../data/rfc/rfc6632.txt- Services to Dynamically Provision View-Based Access
../data/rfc/rfc6632.txt- Control Model User-to-Group Mappings", RFC 6065,
../data/rfc/rfc6632.txt- December 2010.
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of
--
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt-A.2. Protocols Matched to Management Tasks
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- This subsection classifies the management protocols matching to the
../data/rfc/rfc6632.txt: management tasks for fault, configuration, accounting, performance,
../data/rfc/rfc6632.txt- and security management.
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- +------------+------------+-------------+--------------+------------+
../data/rfc/rfc6632.txt: | Fault Mgmt | Config. | Accounting | Performance | Security |
../data/rfc/rfc6632.txt- | | Mgmt | Mgmt | Mgmt | Mgmt |
../data/rfc/rfc6632.txt- +------------+------------+-------------+--------------+------------+
../data/rfc/rfc6632.txt- | SNMP | SNMP | SNMP | SNMP | |
../data/rfc/rfc6632.txt- | notif. | config. | monitoring | monitoring | |
../data/rfc/rfc6632.txt- | with trap | with set | with get | with get | |
--
../data/rfc/rfc6632.txt- | | | | | |
../data/rfc/rfc6632.txt- | PSAMP | NETCONF | PSAMP | PSAMP | |
../data/rfc/rfc6632.txt- | (S. 2.3) | (S. 2.4.1) | (S. 2.3) | (S. 2.3) | |
../data/rfc/rfc6632.txt- | | | | | |
../data/rfc/rfc6632.txt- | Syslog | ANCP | RADIUS | | RADIUS |
../data/rfc/rfc6632.txt: | (S. 2.2) | (S. 3.8) | Accounting | | Authent.& |
../data/rfc/rfc6632.txt- | | | (S. 3.5) | | Authoriz. |
../data/rfc/rfc6632.txt- | | | | | (S. 3.5) |
../data/rfc/rfc6632.txt- | | | | | |
../data/rfc/rfc6632.txt- | | AUTOCONF | Diameter | | Diameter |
../data/rfc/rfc6632.txt: | | (S. 3.1.2) | Accounting | | Authent.& |
../data/rfc/rfc6632.txt- | | | (S. 3.6) | | Authoriz. |
../data/rfc/rfc6632.txt- | | | | | (S. 3.6) |
../data/rfc/rfc6632.txt- | | | | | |
../data/rfc/rfc6632.txt- | | ACAP | | | |
../data/rfc/rfc6632.txt- | | (S. 3.9) | | | |
--
../data/rfc/rfc6632.txt- | NETCONF (except notifications) | NETCONF notifications |
../data/rfc/rfc6632.txt- | (Section 2.4.1) | (Section 2.4.1) |
../data/rfc/rfc6632.txt- | CAPWAP (Section 3.7) | Syslog (Section 2.2) |
../data/rfc/rfc6632.txt- | | IPFIX (Section 2.3) |
../data/rfc/rfc6632.txt- | | PSAMP (Section 2.3) |
../data/rfc/rfc6632.txt: | | RADIUS accounting |
../data/rfc/rfc6632.txt- | | (Section 3.5) |
../data/rfc/rfc6632.txt: | | Diameter accounting |
../data/rfc/rfc6632.txt- | | (Section 3.6) |
../data/rfc/rfc6632.txt- +---------------------------------+---------------------------------+
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- Table 3: Protocol Classification by Push versus Pull Mechanism
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt-A.4. Passive versus Active Monitoring
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- Monitoring can be divided into two categories: passive and active
../data/rfc/rfc6632.txt- monitoring. Passive monitoring can perform the network traffic
../data/rfc/rfc6632.txt: monitoring, monitoring of a device, or the accounting of network
../data/rfc/rfc6632.txt- resource consumption by users. Active monitoring, as used in this
../data/rfc/rfc6632.txt- document, focuses mainly on active network monitoring and relies on
../data/rfc/rfc6632.txt- the injection of specific traffic (also called "synthetic traffic"),
../data/rfc/rfc6632.txt- which is then monitored. The monitoring focus is indicated in the
../data/rfc/rfc6632.txt: table below as "network", "device", or "accounting".
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- This classification excludes non-monitoring protocols, such as
../data/rfc/rfc6632.txt- configuration protocols: Ad hoc network autoconfiguration, ANCP, and
../data/rfc/rfc6632.txt- XCAP. Note that some of the active monitoring protocols, in the
../data/rfc/rfc6632.txt- context of the data path, e.g., ICMP Ping and Traceroute [RFC1470],
--
../data/rfc/rfc6632.txt- | PSAMP (network) (Section 2.3) | TWAMP (network) (Section 3.4) |
../data/rfc/rfc6632.txt- | SNMP (network and device) | |
../data/rfc/rfc6632.txt- | (Section 2.1) | |
../data/rfc/rfc6632.txt- | NETCONF (device) | |
../data/rfc/rfc6632.txt- | (Section 2.4.1) | |
../data/rfc/rfc6632.txt: | RADIUS (accounting) | |
../data/rfc/rfc6632.txt- | (Section 3.5) | |
../data/rfc/rfc6632.txt: | Diameter (accounting) | |
../data/rfc/rfc6632.txt- | (Section 3.6) | |
../data/rfc/rfc6632.txt- | CAPWAP (device) (Section 3.7) | |
../data/rfc/rfc6632.txt- +---------------------------------+---------------------------------+
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- Table 4: Protocols for Passive and Active Monitoring and Their
--
../data/rfc/rfc6632.txt- passive monitoring, e.g., with the NETCONF Monitoring YANG module
../data/rfc/rfc6632.txt- [RFC6022] for the monitoring of the NETCONF protocol. CAPWAP
../data/rfc/rfc6632.txt- monitors the status of a Wireless Termination Point.
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- RADIUS and diameter are considered passive monitoring protocols as
../data/rfc/rfc6632.txt: they perform accounting, i.e., counting the number of packets/bytes
../data/rfc/rfc6632.txt- for a specific user.
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt-A.5. Supported Data Model Types and Their Extensibility
../data/rfc/rfc6632.txt-
../data/rfc/rfc6632.txt- The following table matches the protocols to the associated data
--
../data/rfc/rfc6632.txt- The basic objective of energy management is operating communication
../data/rfc/rfc6632.txt- networks and other equipment with a minimal amount of energy while
../data/rfc/rfc6632.txt- still providing sufficient performance to meet service-level
../data/rfc/rfc6632.txt- objectives. Today, most networking and network-attached devices
../data/rfc/rfc6632.txt- neither monitor nor allow controlled energy usage as they are mainly
../data/rfc/rfc6632.txt: instrumented for functions such as fault, configuration, accounting,
../data/rfc/rfc6632.txt- performance, and security management. These devices are not
../data/rfc/rfc6632.txt- instrumented to be aware of energy consumption. There are very few
../data/rfc/rfc6632.txt- means specified in IETF documents for energy management, which
../data/rfc/rfc6632.txt- includes the areas of power monitoring, energy monitoring, and power
../data/rfc/rfc6632.txt- state control.
Binary file ../data/rfc/rfc674.txt matches
--
../data/rfc/rfc6159.txt-Tsou, et al. Informational [Page 3]
../data/rfc/rfc6159.txt-
../data/rfc/rfc6159.txt-RFC 6159 Diameter Explicit Routing April 2011
../data/rfc/rfc6159.txt-
../data/rfc/rfc6159.txt-
../data/rfc/rfc6159.txt: Authentication, Authorization, and Accounting (AAA) Relays
../data/rfc/rfc6159.txt- Other Diameter nodes interspersed between the ER-Originator,
../data/rfc/rfc6159.txt- ER-Proxies, and the ER-Destination. These nodes represent
../data/rfc/rfc6159.txt- existing Diameter agents and proxies that do not participate in ER
../data/rfc/rfc6159.txt- and do not recognize Explicit-Path Attribute Value Pairs (AVPs).
../data/rfc/rfc6159.txt-
--
../data/rfc/rfc5164.txt- information to make decisions about what steps to take next. It
../data/rfc/rfc5164.txt- is essential that there is some way to ensure that the information
../data/rfc/rfc5164.txt- received is from a trustworthy source. This requirement should
../data/rfc/rfc5164.txt- reuse trust relationships that have already been established in
../data/rfc/rfc5164.txt- the network, for example, on the relationships established by the
../data/rfc/rfc5164.txt: Authentication, Authorization, and Accounting (AAA) infrastructure
../data/rfc/rfc5164.txt- after a mutual authentication, or on the certificate
../data/rfc/rfc5164.txt- infrastructure required to support SEND [10]. Section 6 provides
../data/rfc/rfc5164.txt- a more complete analysis.
../data/rfc/rfc5164.txt-
../data/rfc/rfc5164.txt- Security association management: A common security association
--
../data/rfc/rfc5973.txt- with respect to the NATFW NSLP protocol interaction.
../data/rfc/rfc5973.txt-
../data/rfc/rfc5973.txt- The security solutions for providing authorization have a direct
../data/rfc/rfc5973.txt- impact on the treatment of different NSLPs. As it can be seen from
../data/rfc/rfc5973.txt- the QoS NSLP [RFC5974] and the corresponding Diameter QoS work
../data/rfc/rfc5973.txt: [RFC5866], accounting and charging seems to play an important role
../data/rfc/rfc5973.txt- for QoS reservations, whereas monetary aspects might only indirectly
../data/rfc/rfc5973.txt- effect authorization decisions for NAT and firewall signaling.
../data/rfc/rfc5973.txt- Hence, there are differences in the semantics of authorization
../data/rfc/rfc5973.txt- handling between QoS and NATFW signaling. A NATFW-aware node will
../data/rfc/rfc5973.txt- most likely want to authorize the entity (e.g., user or machine)
--
../data/rfc/rfc949.txt- include it in a suitable response-code's free text field (unless, of
../data/rfc/rfc949.txt- course, an avalanche of comments comes in urging it not be done at
../data/rfc/rfc949.txt- all)?
../data/rfc/rfc949.txt-
../data/rfc/rfc949.txt- Note, by the way, that the intent here is emphatically not to
../data/rfc/rfc949.txt: sidestep whatever access control, authentication, and accounting
../data/rfc/rfc949.txt- mechanisms Hosts might have in play before the user can do an old
../data/rfc/rfc949.txt- STOR or a new STOU, but with suitable publicized ID's and passwords
../data/rfc/rfc949.txt- it could be almost as good as the proposal made in RFC 505.
../data/rfc/rfc949.txt-
../data/rfc/rfc949.txt-RECOMMENDATION
--
../data/rfc/rfc5247.txt- This document specifies the EAP key hierarchy and provides a
../data/rfc/rfc5247.txt- framework for the transport and usage of keying material and
../data/rfc/rfc5247.txt- parameters generated by EAP methods. It also provides a detailed
../data/rfc/rfc5247.txt- security analysis, describing the conditions under which the
../data/rfc/rfc5247.txt- requirements described in "Guidance for Authentication,
../data/rfc/rfc5247.txt: Authorization, and Accounting (AAA) Key Management" [RFC4962] can be
../data/rfc/rfc5247.txt- satisfied.
../data/rfc/rfc5247.txt-
../data/rfc/rfc5247.txt-1.1. Requirements Language
../data/rfc/rfc5247.txt-
../data/rfc/rfc5247.txt- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
--
../data/rfc/rfc5247.txt-Aboba, et al. Standards Track [Page 3]
../data/rfc/rfc5247.txt-
../data/rfc/rfc5247.txt-RFC 5247 EAP Key Management Framework August 2008
../data/rfc/rfc5247.txt-
../data/rfc/rfc5247.txt-
../data/rfc/rfc5247.txt: AAA Authentication, Authorization, and Accounting
../data/rfc/rfc5247.txt- AAA protocols with EAP support include "RADIUS Support for EAP"
../data/rfc/rfc5247.txt- [RFC3579] and "Diameter EAP Application" [RFC4072]. In this
../data/rfc/rfc5247.txt- document, the terms "AAA server" and "backend authentication
../data/rfc/rfc5247.txt- server" are used interchangeably.
../data/rfc/rfc5247.txt-
--
../data/rfc/rfc5247.txt- While the authenticator can implement some EAP methods locally and
../data/rfc/rfc5247.txt- use those methods to authenticate local users, it can at the same
../data/rfc/rfc5247.txt- time act as a pass-through for other users and methods, forwarding
../data/rfc/rfc5247.txt- EAP packets back and forth between the backend authentication server
../data/rfc/rfc5247.txt- and the peer. This is accomplished by encapsulating EAP packets
../data/rfc/rfc5247.txt: within the Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc5247.txt- protocol spoken between the authenticator and backend authentication
../data/rfc/rfc5247.txt- server. AAA protocols supporting EAP include RADIUS [RFC3579] and
../data/rfc/rfc5247.txt- Diameter [RFC4072].
../data/rfc/rfc5247.txt-
../data/rfc/rfc5247.txt- It is a fundamental property of EAP that at the EAP method layer, the
--
../data/rfc/rfc5247.txt- the same authenticator, increasing backend authentication server
../data/rfc/rfc5247.txt- load.
../data/rfc/rfc5247.txt-
../data/rfc/rfc5247.txt- Since a peer can complete EAP pre-authentication with an
../data/rfc/rfc5247.txt- authenticator without eventually attaching to it, it is possible that
../data/rfc/rfc5247.txt: phase 2 will not occur. In this case, an Accounting-Request
../data/rfc/rfc5247.txt- signifying the start of service will not be sent, or will only be
../data/rfc/rfc5247.txt- sent with a substantial delay after the completion of authentication.
../data/rfc/rfc5247.txt-
../data/rfc/rfc5247.txt-
../data/rfc/rfc5247.txt-
--
../data/rfc/rfc5247.txt- distinguishes an EAP pre-authentication attempt, if the authenticator
../data/rfc/rfc5247.txt- does not always include the SSID for a normal EAP authentication
../data/rfc/rfc5247.txt- attempt, it is possible that the backend authentication server will
../data/rfc/rfc5247.txt- not be able to determine whether a session constitutes an EAP
../data/rfc/rfc5247.txt- pre-authentication attempt, potentially resulting in authorization or
../data/rfc/rfc5247.txt: accounting problems. Where the number of simultaneous sessions is
../data/rfc/rfc5247.txt- limited, the backend authentication server can refuse to authorize a
../data/rfc/rfc5247.txt- valid EAP pre-authentication attempt or can enable the peer to engage
../data/rfc/rfc5247.txt- in more simultaneous sessions than they are authorized for. Where
../data/rfc/rfc5247.txt- EAP pre-authentication occurs with an authenticator which the peer
../data/rfc/rfc5247.txt: never attaches to, it is possible that the backend accounting server
../data/rfc/rfc5247.txt- will not be able to determine whether the absence of an
../data/rfc/rfc5247.txt: Accounting-Request was due to packet loss or a session that never
../data/rfc/rfc5247.txt- started.
../data/rfc/rfc5247.txt-
../data/rfc/rfc5247.txt- In order to enable pre-authentication requests to be handled more
../data/rfc/rfc5247.txt- reliably, it is RECOMMENDED that AAA protocols explicitly identify
../data/rfc/rfc5247.txt- EAP pre-authentication. In order to suppress unnecessary EAP
--
../data/rfc/rfc5247.txt- handoff latency, proactive key distribution schemes typically only
../data/rfc/rfc5247.txt- demonstrate proof of possession of transported keying material
../data/rfc/rfc5247.txt- between the EAP peer and authenticator. During a handoff, the
../data/rfc/rfc5247.txt- backend authentication server is not provided with proof that the
../data/rfc/rfc5247.txt- peer successfully authenticated to an authenticator; instead, the
../data/rfc/rfc5247.txt: authenticator generates a stream of accounting messages without a
../data/rfc/rfc5247.txt- corresponding set of authentication exchanges. As described in
../data/rfc/rfc5247.txt- [MishraPro], knowledge of the neighbor graph can be established via
../data/rfc/rfc5247.txt- static configuration or analysis of authentication exchanges. In
../data/rfc/rfc5247.txt-
../data/rfc/rfc5247.txt-
--
../data/rfc/rfc5247.txt-RFC 5247 EAP Key Management Framework August 2008
../data/rfc/rfc5247.txt-
../data/rfc/rfc5247.txt-
../data/rfc/rfc5247.txt- order to prevent corruption of the neighbor graph, new neighbor graph
../data/rfc/rfc5247.txt- entries can only be created as the result of a successful EAP
../data/rfc/rfc5247.txt: exchange, and accounting packets with no corresponding authentication
../data/rfc/rfc5247.txt- exchange need to be verified to correspond to neighbor graph entries
../data/rfc/rfc5247.txt- (e.g., corresponding to handoffs between neighbors).
../data/rfc/rfc5247.txt-
../data/rfc/rfc5247.txt- In order to prevent compromise of one authenticator from resulting in
../data/rfc/rfc5247.txt- compromise of other authenticators, cryptographic separation needs to
--
../data/rfc/rfc5247.txt- authentication messages, an attacker compromising one authenticator
../data/rfc/rfc5247.txt- could corrupt the neighbor graph, tricking the backend authentication
../data/rfc/rfc5247.txt- server into transporting keying material to arbitrary authenticators.
../data/rfc/rfc5247.txt- While this would not enable recovery of EAP keying material without
../data/rfc/rfc5247.txt- breaking fundamental cryptographic assumptions, it could enable
../data/rfc/rfc5247.txt: subsequent fraudulent accounting messages, or allow an attacker to
../data/rfc/rfc5247.txt- disrupt service by increasing load on the backend authentication
../data/rfc/rfc5247.txt- server or thrashing the authenticator key cache.
../data/rfc/rfc5247.txt-
../data/rfc/rfc5247.txt- Since proactive key distribution requires the distribution of derived
../data/rfc/rfc5247.txt- keying material to candidate authenticators, the effectiveness of
--
../data/rfc/rfc5247.txt-
../data/rfc/rfc5247.txt- In Access-Request Packets, the Authenticator value is a 16 octet
../data/rfc/rfc5247.txt- random number, called the Request Authenticator.
../data/rfc/rfc5247.txt-
../data/rfc/rfc5247.txt- However, some RADIUS packets are not replay protected. In
../data/rfc/rfc5247.txt: Accounting, Disconnect, and Care-of Address (CoA)-Request packets,
../data/rfc/rfc5247.txt- the Request Authenticator contains a keyed Message Integrity Code
../data/rfc/rfc5247.txt: (MIC) rather than a nonce. The Response Authenticator in Accounting,
../data/rfc/rfc5247.txt- Disconnect, and CoA-Response packets also contains a keyed MIC whose
../data/rfc/rfc5247.txt- calculation does not depend on a nonce in either the Request or
../data/rfc/rfc5247.txt- Response packets. Therefore, unless an Event-Timestamp attribute is
../data/rfc/rfc5247.txt- included or IPsec is used, it is possible that the recipient will not
../data/rfc/rfc5247.txt- be able to determine whether these packets have been replayed. This
--
../data/rfc/rfc5247.txt- [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
../data/rfc/rfc5247.txt- H. Levkowetz, Ed., "Extensible Authentication Protocol
../data/rfc/rfc5247.txt- (EAP)", RFC 3748, June 2004.
../data/rfc/rfc5247.txt-
../data/rfc/rfc5247.txt- [RFC4962] Housley, R. and B. Aboba, "Guidance for
../data/rfc/rfc5247.txt: Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc5247.txt- Key Management", BCP 132, RFC 4962, July 2007.
../data/rfc/rfc5247.txt-
../data/rfc/rfc5247.txt-6.2. Informative References
../data/rfc/rfc5247.txt-
../data/rfc/rfc5247.txt- [8021XPreAuth] Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff
--
../data/rfc/rfc5787.txt- 3. Reachability ....................................................6
../data/rfc/rfc5787.txt- 3.1. Node IPv4 Local Prefix Sub-TLV .............................6
../data/rfc/rfc5787.txt- 3.2. Node IPv6 Local Prefix Sub-TLV .............................7
../data/rfc/rfc5787.txt- 4. Link Attribute ..................................................8
../data/rfc/rfc5787.txt- 4.1. Local Adaptation ...........................................8
../data/rfc/rfc5787.txt: 4.2. Bandwidth Accounting .......................................9
../data/rfc/rfc5787.txt- 5. Routing Information Scope .......................................9
../data/rfc/rfc5787.txt- 5.1. Terminology and Identification .............................9
../data/rfc/rfc5787.txt- 5.2. Link Advertisement (Local and Remote TE Router ID
../data/rfc/rfc5787.txt- Sub-TLV) ..................................................10
../data/rfc/rfc5787.txt- 5.3. Reachability Advertisement (Local TE Router ID sub-TLV) ...11
--
../data/rfc/rfc5787.txt- in any compatibility issues.
../data/rfc/rfc5787.txt-
../data/rfc/rfc5787.txt- Further refinement of the ISCD sub-TLV for multi-layer networks is
../data/rfc/rfc5787.txt- outside the scope of this document.
../data/rfc/rfc5787.txt-
../data/rfc/rfc5787.txt:4.2. Bandwidth Accounting
../data/rfc/rfc5787.txt-
../data/rfc/rfc5787.txt- GMPLS routing defines an Interface Switching Capability Descriptor
../data/rfc/rfc5787.txt- (ISCD) that delivers, among other things, information about the
../data/rfc/rfc5787.txt- (maximum/minimum) bandwidth per priority that a Label Switched Path
../data/rfc/rfc5787.txt- (LSP) can make use of. Per [RFC4202] and [RFC4203], one or more ISCD
../data/rfc/rfc5787.txt- sub-TLVs can be associated with an interface. This information,
../data/rfc/rfc5787.txt- combined with the Unreserved Bandwidth (sub-TLV defined in [RFC3630],
../data/rfc/rfc5787.txt: Section 2.5.8), provides the basis for bandwidth accounting.
../data/rfc/rfc5787.txt-
../data/rfc/rfc5787.txt- In the ASON context, additional information may be included when the
../data/rfc/rfc5787.txt- representation and information in the other advertised fields are not
../data/rfc/rfc5787.txt- sufficient for a specific technology (e.g., SDH). The definition of
../data/rfc/rfc5787.txt- technology-specific information elements is beyond the scope of this
--
../data/rfc/rfc5787.txt-
../data/rfc/rfc5787.txt- Management plane: performs management functions for the transport
../data/rfc/rfc5787.txt- plane, the control plane, and the system as a whole. It also
../data/rfc/rfc5787.txt- provides coordination between all the planes. The following
../data/rfc/rfc5787.txt- management functional areas are performed in the management plane:
../data/rfc/rfc5787.txt: performance, fault, configuration, accounting, and security
../data/rfc/rfc5787.txt- management.
../data/rfc/rfc5787.txt-
../data/rfc/rfc5787.txt- Management domain: (See Recommendation G.805.) A management domain
../data/rfc/rfc5787.txt- defines a collection of managed objects that are grouped to meet
../data/rfc/rfc5787.txt- organizational requirements according to geography, technology,
--
../data/rfc/rfc4673.txt- to handle the Disconnect and Change-of-Authorization (CoA) messages
../data/rfc/rfc4673.txt- as described in [RFC3576]. As a result, the effective management of
../data/rfc/rfc4673.txt- RADIUS Dynamic Authorization entities is of considerable importance.
../data/rfc/rfc4673.txt- This RADIUS Dynamic Authorization Server (DAS) MIB complements the
../data/rfc/rfc4673.txt- managed objects used for managing RADIUS authentication and
../data/rfc/rfc4673.txt: accounting clients as described in [RFC4668] and [RFC4670],
../data/rfc/rfc4673.txt- respectively.
../data/rfc/rfc4673.txt-
../data/rfc/rfc4673.txt-1.1. Requirements Notation
../data/rfc/rfc4673.txt-
../data/rfc/rfc4673.txt- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
--
../data/rfc/rfc4673.txt- [RFC4671] describes the MIB for a RADIUS Acct Server MIB.
../data/rfc/rfc4673.txt-
../data/rfc/rfc4673.txt- [RFC4672] describes the MIB for a RADIUS Dynamic Auth Client.
../data/rfc/rfc4673.txt-
../data/rfc/rfc4673.txt- A NAS typically implements the MIBs for a RADIUS Authentication
../data/rfc/rfc4673.txt: Client, a RADIUS accounting client, and a RADIUS Dynamic
../data/rfc/rfc4673.txt- Authorization Server. However, any one MIB can be implemented
../data/rfc/rfc4673.txt- without implementing any of the other MIBs; i.e., the MIBs have no
../data/rfc/rfc4673.txt- dependencies on each other. A typical case would be for a device to
../data/rfc/rfc4673.txt: implement the MIBs RADIUS authentication server, RADIUS accounting
../data/rfc/rfc4673.txt- server, and RADIUS Dynamic Authorization Client. A RADIUS proxy
../data/rfc/rfc4673.txt- might implement any, all, or a subset of the MIBs listed above and
../data/rfc/rfc4673.txt- the MIB as defined in this document.
../data/rfc/rfc4673.txt-
../data/rfc/rfc4673.txt-
--
../data/rfc/rfc4673.txt- RFC 4668, August 2006.
../data/rfc/rfc4673.txt-
../data/rfc/rfc4673.txt- [RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6",
../data/rfc/rfc4673.txt- RFC 4669, August 2006.
../data/rfc/rfc4673.txt-
../data/rfc/rfc4673.txt: [RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC
../data/rfc/rfc4673.txt- 4670, August 2006.
../data/rfc/rfc4673.txt-
../data/rfc/rfc4673.txt: [RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6", RFC
../data/rfc/rfc4673.txt- 4671, August 2006.
../data/rfc/rfc4673.txt-
../data/rfc/rfc4673.txt- [RFC4672] De Cnodder, S., Jonnala, N., and M. Chiba, "RADIUS Dynamic
../data/rfc/rfc4673.txt- Authorization Client MIB", RFC 4672, September 2006.
../data/rfc/rfc4673.txt-
--
../data/rfc/rfc6036.txt- balancers; VPN boxes; some SIP platforms; management interfaces &
../data/rfc/rfc6036.txt- systems; firewalls; billing systems. When asked if such devices can
../data/rfc/rfc6036.txt- be field-upgraded, the answers were gloomy: 5 yes, 4 partially, 10
../data/rfc/rfc6036.txt- no, and numerous "don't know" or "hopefully".
../data/rfc/rfc6036.txt-
../data/rfc/rfc6036.txt: 84% support or plan DNS Authentication, Authorization, Accounting,
../data/rfc/rfc6036.txt- and Auditing (AAAA) queries over IPv6, and all but one of these
../data/rfc/rfc6036.txt- include reverse DNS lookup for IPv6.
../data/rfc/rfc6036.txt-
../data/rfc/rfc6036.txt- The ISPs surveyed have prefixes ranging from /19 to /48, and have a
../data/rfc/rfc6036.txt- variety of policies for customer prefixes. Fifteen ISPs offer more
--
../data/rfc/rfc6036.txt-
../data/rfc/rfc6036.txt- About 50% of ISPs already operate or plan dual-stack SMTP, Post
../data/rfc/rfc6036.txt- Office Protocol 3 (POP3), IMAP, and HTTP services. In terms of
../data/rfc/rfc6036.txt- internal services, it seems that firewalls, intrusion detection,
../data/rfc/rfc6036.txt- address management, monitoring, and network management tools are also
../data/rfc/rfc6036.txt: around the 50% mark. However, accounting and billing software is
../data/rfc/rfc6036.txt- only ready at 23% of ISPs.
../data/rfc/rfc6036.txt-
../data/rfc/rfc6036.txt- Considering IPv4-IPv6 interworking, 58% of ISPs don't expect to have
../data/rfc/rfc6036.txt- IPv6-only customers (but mobile operators are certain they will have
../data/rfc/rfc6036.txt- millions). Five ISPs report customers who explicitly refused to
--
../data/rfc/rfc6036.txt-RFC 6036 ISP IPv6 Scenarios October 2010
../data/rfc/rfc6036.txt-
../data/rfc/rfc6036.txt-
../data/rfc/rfc6036.txt- o Intrusion detection systems
../data/rfc/rfc6036.txt-
../data/rfc/rfc6036.txt: o Accounting and billing systems
../data/rfc/rfc6036.txt-
../data/rfc/rfc6036.txt- It is not the purpose of this document to name and shame vendors, but
../data/rfc/rfc6036.txt- today it is becoming urgent for all products to avoid becoming part
../data/rfc/rfc6036.txt- of the IPv4 legacy. ISPs stated that they want consistent feature-
../data/rfc/rfc6036.txt- equivalent support for IPv4 and IPv6 in all equipment and software at
--
../data/rfc/rfc6036.txt-
../data/rfc/rfc6036.txt- * Intrusion detection: 10 yes, 2 plan, 13 no
../data/rfc/rfc6036.txt-
../data/rfc/rfc6036.txt- * Address management software: 15 yes, 1 plan, 13 no
../data/rfc/rfc6036.txt-
../data/rfc/rfc6036.txt: * Accounting software: 7 yes, 21 no
../data/rfc/rfc6036.txt-
../data/rfc/rfc6036.txt- * Monitoring software: 16 yes, 2 partial, 2 plan, 11 no
../data/rfc/rfc6036.txt-
../data/rfc/rfc6036.txt- * Network management tools: 13 yes, 4 partial, 1 plan, 11 no
../data/rfc/rfc6036.txt-
--
../data/rfc/rfc6036.txt-
../data/rfc/rfc6036.txt- 28.2. Intrusion detection
../data/rfc/rfc6036.txt-
../data/rfc/rfc6036.txt- 28.3. Address management software
../data/rfc/rfc6036.txt-
../data/rfc/rfc6036.txt: 28.4. Accounting software
../data/rfc/rfc6036.txt-
../data/rfc/rfc6036.txt- 28.5. Monitoring software
../data/rfc/rfc6036.txt-
../data/rfc/rfc6036.txt- 28.6. Network management tools
../data/rfc/rfc6036.txt-
--
../data/rfc/rfc3466.txt- provider to deliver copies of origin server content to clients from
../data/rfc/rfc3466.txt- multiple diverse locations. The increase in number and diversity of
../data/rfc/rfc3466.txt- location is intended to improve download times and thus improve the
../data/rfc/rfc3466.txt- user experience. A CDN has some combination of a content-delivery
../data/rfc/rfc3466.txt- infrastructure, a request-routing infrastructure, a distribution
../data/rfc/rfc3466.txt: infrastructure, and an accounting infrastructure. The content-
../data/rfc/rfc3466.txt- delivery infrastructure consists of a set of "surrogate" servers [3]
../data/rfc/rfc3466.txt- that deliver copies of content to sets of users. The request-routing
../data/rfc/rfc3466.txt- infrastructure consists of mechanisms that move a client toward a
../data/rfc/rfc3466.txt-
../data/rfc/rfc3466.txt-
--
../data/rfc/rfc3466.txt-RFC 3466 A Model for Content Internetworking (CDI) February 2003
../data/rfc/rfc3466.txt-
../data/rfc/rfc3466.txt-
../data/rfc/rfc3466.txt- rendezvous with a surrogate. The distribution infrastructure
../data/rfc/rfc3466.txt- consists of mechanisms that move content from the origin server to
../data/rfc/rfc3466.txt: the surrogates. Finally, the accounting infrastructure tracks and
../data/rfc/rfc3466.txt- collects data on request-routing, distribution, and delivery
../data/rfc/rfc3466.txt- functions within the CDN.
../data/rfc/rfc3466.txt-
../data/rfc/rfc3466.txt- The following diagram depicts a simple CDN as described above:
../data/rfc/rfc3466.txt-
--
../data/rfc/rfc3466.txt- internetworking and this vocabulary are applicable to other protocols
../data/rfc/rfc3466.txt- and styles of content delivery.
../data/rfc/rfc3466.txt-
../data/rfc/rfc3466.txt- Phrases in upper-case refer to other defined terms.
../data/rfc/rfc3466.txt-
../data/rfc/rfc3466.txt: ACCOUNTING
../data/rfc/rfc3466.txt- Measurement and recording of DISTRIBUTION and DELIVERY activities,
../data/rfc/rfc3466.txt- especially when the information recorded is ultimately used as a
../data/rfc/rfc3466.txt- basis for the subsequent transfer of money, goods, or obligations.
../data/rfc/rfc3466.txt-
../data/rfc/rfc3466.txt: ACCOUNTING SYSTEM
../data/rfc/rfc3466.txt: A collection of CONTENT NETWORK ELEMENTS that supports ACCOUNTING
../data/rfc/rfc3466.txt- for a single CONTENT NETWORK.
../data/rfc/rfc3466.txt-
../data/rfc/rfc3466.txt- AUTHORITATIVE REQUEST-ROUTING SYSTEM
../data/rfc/rfc3466.txt- The REQUEST-ROUTING SYSTEM that is the correct/final authority for
../data/rfc/rfc3466.txt- a particular item of CONTENT.
--
../data/rfc/rfc3466.txt- CDN
../data/rfc/rfc3466.txt- Content Delivery Network or Content Distribution Network. A type
../data/rfc/rfc3466.txt- of CONTENT NETWORK in which the CONTENT NETWORK ELEMENTS are
../data/rfc/rfc3466.txt- arranged for more effective delivery of CONTENT to CLIENTS.
../data/rfc/rfc3466.txt- Typically a CDN consists of a REQUEST-ROUTING SYSTEM, SURROGATES,
../data/rfc/rfc3466.txt: a DISTRIBUTION SYSTEM, and an ACCOUNTING SYSTEM.
../data/rfc/rfc3466.txt-
../data/rfc/rfc3466.txt-
../data/rfc/rfc3466.txt-
../data/rfc/rfc3466.txt-
../data/rfc/rfc3466.txt-
--
../data/rfc/rfc3466.txt-Day, et al. Informational [Page 12]
../data/rfc/rfc3466.txt-
../data/rfc/rfc3466.txt-RFC 3466 A Model for Content Internetworking (CDI) February 2003
../data/rfc/rfc3466.txt-
../data/rfc/rfc3466.txt-
../data/rfc/rfc3466.txt: ACCOUNTING INTERNETWORKING
../data/rfc/rfc3466.txt: Interconnection of two or more ACCOUNTING SYSTEMS so as to enable
../data/rfc/rfc3466.txt: the exchange of information between them. The form of ACCOUNTING
../data/rfc/rfc3466.txt- INTERNETWORKING required may depend on the nature of the
../data/rfc/rfc3466.txt- NEGOTIATED RELATIONSHIP between the peering parties -- in
../data/rfc/rfc3466.txt- particular, on the value of the economic exchanges anticipated.
../data/rfc/rfc3466.txt-
../data/rfc/rfc3466.txt- ADVERTISEMENT
--
../data/rfc/rfc3466.txt- about aspects of topology, geography and performance of a CONTENT
../data/rfc/rfc3466.txt- NETWORK. Contrast with CONTENT ADVERTISEMENT, DISTRIBUTION
../data/rfc/rfc3466.txt- ADVERTISEMENT.
../data/rfc/rfc3466.txt-
../data/rfc/rfc3466.txt- BILLING ORGANIZATION
../data/rfc/rfc3466.txt: An entity that operates an ACCOUNTING SYSTEM to support billing
../data/rfc/rfc3466.txt- within a NEGOTIATED RELATIONSHIP with a PUBLISHER.
../data/rfc/rfc3466.txt-
../data/rfc/rfc3466.txt- CONTENT ADVERTISEMENT
../data/rfc/rfc3466.txt- ADVERTISEMENT from a CONTENT NETWORK's REQUEST-ROUTING SYSTEM
../data/rfc/rfc3466.txt- about the availability of one or more collections of CONTENT on a
--
../data/rfc/rfc3466.txt-
../data/rfc/rfc3466.txt- CONTENT INTERNETWORKING GATEWAY (CIG)
../data/rfc/rfc3466.txt- An identifiable element or system through which a CONTENT NETWORK
../data/rfc/rfc3466.txt- can be interconnected with others. A CIG may be the point of
../data/rfc/rfc3466.txt- contact for DISTRIBUTION INTERNETWORKING, REQUEST-ROUTING
../data/rfc/rfc3466.txt: INTERNETWORKING, and/or ACCOUNTING INTERNETWORKING, and thus may
../data/rfc/rfc3466.txt- incorporate some or all of the corresponding systems for the
../data/rfc/rfc3466.txt- CONTENT NETWORK.
../data/rfc/rfc3466.txt-
../data/rfc/rfc3466.txt- CONTENT REPLICATION
../data/rfc/rfc3466.txt- The movement of CONTENT from a CONTENT SOURCE to a CONTENT
--
../data/rfc/rfc3466.txt-
../data/rfc/rfc3466.txt- ENLISTED
../data/rfc/rfc3466.txt- Describes a CONTENT NETWORK that, as part of a NEGOTIATED
../data/rfc/rfc3466.txt- RELATIONSHIP, has accepted a DISTRIBUTION task from another
../data/rfc/rfc3466.txt- CONTENT NETWORK, has agreed to perform REQUEST-ROUTING on behalf
../data/rfc/rfc3466.txt: of another CONTENT NETWORK, or has agreed to provide ACCOUNTING
../data/rfc/rfc3466.txt- data to another CONTENT NETWORK. Contrast with ORIGINATING.
../data/rfc/rfc3466.txt-
../data/rfc/rfc3466.txt- INJECTION
../data/rfc/rfc3466.txt- A "send-only" form of DISTRIBUTION INTERNETWORKING that takes
../data/rfc/rfc3466.txt- place from an ORIGIN to a CONTENT DESTINATION.
--
../data/rfc/rfc3466.txt- ORIGINATING
../data/rfc/rfc3466.txt- Describes a CONTENT NETWORK that, as part of a NEGOTIATED
../data/rfc/rfc3466.txt- RELATIONSHIP, submits a DISTRIBUTION task to another CONTENT
../data/rfc/rfc3466.txt- NETWORK, asks another CONTENT NETWORK to perform REQUEST-ROUTING
../data/rfc/rfc3466.txt- on its behalf, or asks another CONTENT NETWORK to provide
../data/rfc/rfc3466.txt: ACCOUNTING data. Contrast with ENLISTED.
../data/rfc/rfc3466.txt-
../data/rfc/rfc3466.txt-
../data/rfc/rfc3466.txt-
../data/rfc/rfc3466.txt-
../data/rfc/rfc3466.txt-
--
../data/rfc/rfc3466.txt- when both ORIGINATING and ENLISTED networks are involved. CONTENT
../data/rfc/rfc3466.txt- INTERNETWORKING GATEWAYS must allow for mechanisms to prevent theft
../data/rfc/rfc3466.txt- or corruption of CONTENT.
../data/rfc/rfc3466.txt-
../data/rfc/rfc3466.txt- Secure meta-content transfer: CONTENT INTERNETWORKING GATEWAYS must
../data/rfc/rfc3466.txt: support the movement of accurate, reliable, auditable ACCOUNTING
../data/rfc/rfc3466.txt- information between CONTENT NETWORKS. CONTENT INTERNETWORKING
../data/rfc/rfc3466.txt- GATEWAYS must allow for mechanisms to prevent the diversion or
../data/rfc/rfc3466.txt: corruption of ACCOUNTING data and similar meta-content.
../data/rfc/rfc3466.txt-
../data/rfc/rfc3466.txt-7. Acknowledgements
../data/rfc/rfc3466.txt-
../data/rfc/rfc3466.txt- The authors acknowledge the contributions and comments of Fred
../data/rfc/rfc3466.txt- Douglis (AT&T), Don Gilletti (CacheFlow), Markus Hoffmann (Lucent),
--
../data/rfc/rfc4186.txt-
../data/rfc/rfc4186.txt- This document frequently uses the following terms and abbreviations:
../data/rfc/rfc4186.txt-
../data/rfc/rfc4186.txt- AAA protocol
../data/rfc/rfc4186.txt-
../data/rfc/rfc4186.txt: Authentication, Authorization, and Accounting protocol
../data/rfc/rfc4186.txt-
../data/rfc/rfc4186.txt- AuC
../data/rfc/rfc4186.txt-
../data/rfc/rfc4186.txt- Authentication Centre. The GSM network element that provides
../data/rfc/rfc4186.txt- the authentication triplets for authenticating
--
../data/rfc/rfc2768.txt- services requiring research and development. The workshop
../data/rfc/rfc2768.txt- participants discussed the definition of middleware in general,
../data/rfc/rfc2768.txt- examined the applications perspective, detailed underlying network
../data/rfc/rfc2768.txt- transport capabilities relevant to middleware services, and then
../data/rfc/rfc2768.txt- covered various specific examples of middleware components. These
../data/rfc/rfc2768.txt: included APIs, authentication, authorization, and accounting (AAA)
../data/rfc/rfc2768.txt- issues, policy framework, directories, resource management, networked
../data/rfc/rfc2768.txt- information discovery and retrieval services, quality of service,
../data/rfc/rfc2768.txt-
../data/rfc/rfc2768.txt-
../data/rfc/rfc2768.txt-
--
../data/rfc/rfc2768.txt- with remote execution, or for linking together multiple processing
../data/rfc/rfc2768.txt- steps.
../data/rfc/rfc2768.txt-
../data/rfc/rfc2768.txt-6.0 IETF AAA
../data/rfc/rfc2768.txt-
../data/rfc/rfc2768.txt: The IETF AAA (authentication, authorization, and accounting) effort
../data/rfc/rfc2768.txt- is but one of many IETF security initiatives. It depends heavily on a
../data/rfc/rfc2768.txt- Public key infrastructure, which is intended to provide a framework
../data/rfc/rfc2768.txt- which will support a range of trust/hierarchy environments and a
../data/rfc/rfc2768.txt- range of usage environments (RFC1422 is an example of one such
../data/rfc/rfc2768.txt- model).
--
../data/rfc/rfc2768.txt- group efforts are focused on many issues pertaining to middleware,
../data/rfc/rfc2768.txt- including defining processes for access/admission control and
../data/rfc/rfc2768.txt- identification (process for determining a unique entity),
../data/rfc/rfc2768.txt- authentication (process for validating that identity), authorization
../data/rfc/rfc2768.txt- (process for determining an eligibility for resource
../data/rfc/rfc2768.txt: requests/utilization) and accounting (at least to the degree that
../data/rfc/rfc2768.txt- resource utilization is recorded). To some degree, AAA provides for
../data/rfc/rfc2768.txt- addressing certain levels of security, but only at a preliminary
../data/rfc/rfc2768.txt- level. Currently, AAA protocols exist, although not as an integrated
../data/rfc/rfc2768.txt- model or standard. One consideration for AAA is to provide for
../data/rfc/rfc2768.txt- various levels of granularity. Even if we don't yet have an
--
../data/rfc/rfc2768.txt- attention must be paid to providing the end-user/customer or network
../data/rfc/rfc2768.txt- administrator with the tools they require to securely and dynamically
../data/rfc/rfc2768.txt- manage an adaptable network infrastructure. Differentiated services
../data/rfc/rfc2768.txt- means that theoretically some traffic gets better service than other
../data/rfc/rfc2768.txt- traffic; subsequently, one can expect to pay for better service,
../data/rfc/rfc2768.txt: which means that accounting and billing services will be one of the
../data/rfc/rfc2768.txt- important middleware core components that others will rely upon. The
../data/rfc/rfc2768.txt- model and protocols necessary to accomplish this are not developed
../data/rfc/rfc2768.txt- yet.
../data/rfc/rfc2768.txt-
../data/rfc/rfc2768.txt:12.0 Authentication, Authorization, and Accounting
../data/rfc/rfc2768.txt-
../data/rfc/rfc2768.txt- The IETF's AAA working group is focusing on the requirements for
../data/rfc/rfc2768.txt: supporting authentication, authorization, accounting, and auditing of
../data/rfc/rfc2768.txt- access to and services provided by network resource managers (e.g.,
../data/rfc/rfc2768.txt- bandwidth brokers). These processes constitute an important security
../data/rfc/rfc2768.txt- infrastructure that will be relied upon by middleware and
../data/rfc/rfc2768.txt- applications. However, these components are only basic security
../data/rfc/rfc2768.txt- components. A public key infrastructure (PKI) was identified as a
../data/rfc/rfc2768.txt- crucial security service infrastructure component. For example, the
../data/rfc/rfc2768.txt- PKI will be required to support the transitivity of authentication,
../data/rfc/rfc2768.txt: authorization, and access control and, where appropriate, accounting
../data/rfc/rfc2768.txt- and billing. It was noted that, except for issues dealing with group
../data/rfc/rfc2768.txt- security and possibly more efficient and simple management, there are
../data/rfc/rfc2768.txt- no real technical challenges preventing the wide scale deployment of
../data/rfc/rfc2768.txt- a PKI support structure at this time. Instead, the main obstacles to
../data/rfc/rfc2768.txt- overcome are mostly political and economic in nature. However,
--
../data/rfc/rfc2768.txt- public key infrastructure, notary services and provenance
../data/rfc/rfc2768.txt- verification. As we move from a relatively dumb network (e.g. best
../data/rfc/rfc2768.txt- effort IP) to an Internet with embedded intelligence (e.g., DiffServ,
../data/rfc/rfc2768.txt- IntServ, bandwidth brokers, directory-enabled networks, etc.), the
../data/rfc/rfc2768.txt- secure exchange of information will become even more important. In
../data/rfc/rfc2768.txt: addition, as we start to provide differentiated services, accounting
../data/rfc/rfc2768.txt- and statistics gathering will become much more important. We also
../data/rfc/rfc2768.txt- need to provide for the integrity and security of collecting,
../data/rfc/rfc2768.txt- analyzing, and transporting network management and monitoring
../data/rfc/rfc2768.txt- information. And the issues of data privacy and integrity, along
../data/rfc/rfc2768.txt- with addressing denial of service and non-repudiation, cannot be
--
../data/rfc/rfc2768.txt- network management or high energy physics applications) wishing to
../data/rfc/rfc2768.txt- utilize the network or distributed data/computation infrastructure.
../data/rfc/rfc2768.txt- This document discusses some of the basic and core middleware
../data/rfc/rfc2768.txt- services, which include, but are not limited to: directories,
../data/rfc/rfc2768.txt- name/address resolution services, security services (i.e.,
../data/rfc/rfc2768.txt: authentication, authorization, accounting, and access control),
../data/rfc/rfc2768.txt: network management, network monitoring, time servers, and accounting.
../data/rfc/rfc2768.txt- Network level capabilities, such as multicast and DiffServ, are not
../data/rfc/rfc2768.txt-
../data/rfc/rfc2768.txt-
../data/rfc/rfc2768.txt-
../data/rfc/rfc2768.txt-Aiken, et al. Informational [Page 24]
--
../data/rfc/rfc2768.txt-
../data/rfc/rfc2768.txt- classified as middleware; rather, they are enabling infrastructure
../data/rfc/rfc2768.txt- services upon which middleware will be built or which middleware may
../data/rfc/rfc2768.txt- use and manage. A second level of important middleware services,
../data/rfc/rfc2768.txt- which builds upon these core set of services, may include
../data/rfc/rfc2768.txt: accounting/billing, resource managers, single sign-on services,
../data/rfc/rfc2768.txt- globally unique names, metadata servers, and locators.
../data/rfc/rfc2768.txt-
../data/rfc/rfc2768.txt- A recognized goal is to provide a set of middleware services that
../data/rfc/rfc2768.txt- enable access to and management of the underlying network
../data/rfc/rfc2768.txt- infrastructure and support applications wishing to make use of that
--
../data/rfc/rfc2768.txt- - avoiding deadlock and ensuring efficiency with resource managers
../data/rfc/rfc2768.txt- - network management tools and APIs that provide macroscopic and
../data/rfc/rfc2768.txt- microscopic real-time infrastructure
../data/rfc/rfc2768.txt- - information to middleware services and applications (not just MIBs
../data/rfc/rfc2768.txt- and SNMP access)
../data/rfc/rfc2768.txt: - domain and inter-domain accounting and billing
../data/rfc/rfc2768.txt- - monitoring and verification services of contracted infrastructure
../data/rfc/rfc2768.txt- services
../data/rfc/rfc2768.txt- - enhanced locators that can locate resources and resource managers
../data/rfc/rfc2768.txt-
../data/rfc/rfc2768.txt-
--
../data/rfc/rfc2768.txt-
../data/rfc/rfc2768.txt- - cross administrative policy negotiation and authentication
../data/rfc/rfc2768.txt- - middleware bypass (i.e. access to raw system or network resources
../data/rfc/rfc2768.txt- metadata (i.e., data that is used to describe data found in
../data/rfc/rfc2768.txt- directories or exchanged between services such as resource
../data/rfc/rfc2768.txt: managers, PDPs, PEPs, directories, accounting and billing
../data/rfc/rfc2768.txt- services, etc.)
../data/rfc/rfc2768.txt- - middleware support for mobile or nomadic use
../data/rfc/rfc2768.txt- - support for availability of resources (i.e. replication and load
../data/rfc/rfc2768.txt- balancing
../data/rfc/rfc2768.txt-
--
../data/rfc/rfc8256.txt-
../data/rfc/rfc8256.txt- As an example, the old and new transport resources (e.g., LSP
../data/rfc/rfc8256.txt- tunnels) might compete with each other for resources that they have
../data/rfc/rfc8256.txt- in common. Depending on availability of resources, this competition
../data/rfc/rfc8256.txt- can cause admission control to prevent the new LSP tunnel from being
../data/rfc/rfc8256.txt: established as this bandwidth accounting deviates from the
../data/rfc/rfc8256.txt- traditional (non-control plane) management-system operation. While
../data/rfc/rfc8256.txt- SPMEs can be applied in any network context (single-domain, multi-
../data/rfc/rfc8256.txt- domain, single-carrier, multi-carrier, etc.), the main applications
../data/rfc/rfc8256.txt- are in inter-carrier or inter-domain segment monitoring where they
../data/rfc/rfc8256.txt- are typically preconfigured or pre-instantiated. SPME instantiates a
--
../data/rfc/rfc5572.txt- connectivity and a prefix to the internal network.
../data/rfc/rfc5572.txt-
../data/rfc/rfc5572.txt- Automation of the prefix assignment and DNS delegation, done by TSP,
../data/rfc/rfc5572.txt- is a very important feature for a provider in order to substantially
../data/rfc/rfc5572.txt- decrease support costs. The provider can use the same
../data/rfc/rfc5572.txt: Authentication, Authorization, and Accounting (AAA) database that is
../data/rfc/rfc5572.txt- used to authenticate the IPv4 broadband users. Customers can deploy
../data/rfc/rfc5572.txt- home IPv6 networks without any intervention of the provider support
../data/rfc/rfc5572.txt- people.
../data/rfc/rfc5572.txt-
../data/rfc/rfc5572.txt- With the NAT discovery function of TSP, providers can use the same
--
../data/rfc/rfc5873.txt- used for proactively executing EAP authentication and establishing a
../data/rfc/rfc5873.txt- PANA SA (Security Association) between a PaC in an access network and
../data/rfc/rfc5873.txt- a PAA in another access network to which the PaC may move. The
../data/rfc/rfc5873.txt- extension to the PANA protocol is designed to realize direct
../data/rfc/rfc5873.txt- pre-authentication defined in [RFC5836]. How to realize
../data/rfc/rfc5873.txt: authorization and accounting with the use of the pre-authentication
../data/rfc/rfc5873.txt- extension is out of the scope of this document.
../data/rfc/rfc5873.txt-
../data/rfc/rfc5873.txt-1.1. Specification of Requirements
../data/rfc/rfc5873.txt-
../data/rfc/rfc5873.txt- In this document, several words are used to signify the requirements
--
../data/rfc/rfc1280.txt-Internet Activities Board [Page 17]
../data/rfc/rfc1280.txt-
../data/rfc/rfc1280.txt-RFC 1280 IAB Standards March 1992
../data/rfc/rfc1280.txt-
../data/rfc/rfc1280.txt-
../data/rfc/rfc1280.txt: 1272 - Internet Accounting: Background
../data/rfc/rfc1280.txt-
../data/rfc/rfc1280.txt- This is an information document and does not specify any
../data/rfc/rfc1280.txt- level of standard.
../data/rfc/rfc1280.txt-
../data/rfc/rfc1280.txt- 1271 - Remote Network Monitoring Management Information Base
--
../data/rfc/rfc900.txt- 1-149 Unassigned [JBP]
../data/rfc/rfc900.txt- 150 Xerox NS IDP [97,LLG]
../data/rfc/rfc900.txt- 151 Unassigned [JBP]
../data/rfc/rfc900.txt- 152 PARC Universal Protocol [11,HGM]
../data/rfc/rfc900.txt- 153 TIP Status Reporting [JGH]
../data/rfc/rfc900.txt: 154 TIP Accounting [JGH]
../data/rfc/rfc900.txt- 155 Internet Protocol [regular] [31,71,JBP]
../data/rfc/rfc900.txt- 156-158 Internet Protocol [experimental] [31,71,JBP]
../data/rfc/rfc900.txt- 159 Figleaf Link [JBW1]
../data/rfc/rfc900.txt- 160-195 Unassigned [JBP]
../data/rfc/rfc900.txt- 196-247 Experimental Protocols [JBP]
--
../data/rfc/rfc3002.txt- the existing IETF Next Generation Transition (ngtrans) working group,
../data/rfc/rfc3002.txt- provided any mobile IP interoperation issues be identified.
../data/rfc/rfc3002.txt-
../data/rfc/rfc3002.txt-4.4.3
../data/rfc/rfc3002.txt-
../data/rfc/rfc3002.txt: Scalable and widespread authentication, authorization, and accounting
../data/rfc/rfc3002.txt- (AAA) services are critical to the deployment of commercial services
../data/rfc/rfc3002.txt- based on (wireless) mobile IP. Some work is progressing on
../data/rfc/rfc3002.txt- definition of these standards for IP mobility [26,49]. However, due
../data/rfc/rfc3002.txt- to the pivotal role of these protocols on the ability to deploy
../data/rfc/rfc3002.txt- commercial services, it was recommended to make finalization of these
--
../data/rfc/rfc3002.txt- [6] Allman, M., Dawkins, S., Glover, D., Griner, J., Tran, D.,
../data/rfc/rfc3002.txt- Henderson, T., Heidemann, J., Touch, J., Kruse, H., Ostermann,
../data/rfc/rfc3002.txt- S., Scott, K. and J. Semke, "Ongoing TCP Research Related to
../data/rfc/rfc3002.txt- Satellites", RFC 2760, February 2000.
../data/rfc/rfc3002.txt-
../data/rfc/rfc3002.txt: [7] Arkko, J., "Requirements for Internet-Scale Accounting
../data/rfc/rfc3002.txt- Management", Work in Progress.
../data/rfc/rfc3002.txt-
../data/rfc/rfc3002.txt- [8] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol
../data/rfc/rfc3002.txt- Extensions for BGP-4", RFC 2283, February 1998.
../data/rfc/rfc3002.txt-
--
../data/rfc/rfc3002.txt- [25] Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "An
../data/rfc/rfc3002.txt- Extension to the Selective Acknowledgment (SACK) Option for
../data/rfc/rfc3002.txt- TCP", RFC 2883, July 2000.
../data/rfc/rfc3002.txt-
../data/rfc/rfc3002.txt- [26] Glass, S., Hiller, T., Jacobs, S. and C. Perkins, "Mobile IP
../data/rfc/rfc3002.txt: Authentication, Authorization, and Accounting Requirements", RFC
../data/rfc/rfc3002.txt- 2977, October 2000.
../data/rfc/rfc3002.txt-
../data/rfc/rfc3002.txt- [27] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
../data/rfc/rfc3002.txt- location of services (DNS SRV)", RFC 2052, October 1996.
../data/rfc/rfc3002.txt-
--
../data/rfc/rfc5977.txt- |<---------------------------------------------+
../data/rfc/rfc5977.txt-
../data/rfc/rfc5977.txt- Figure 24: RMD message exchange
../data/rfc/rfc5977.txt-
../data/rfc/rfc5977.txt- Authorizing quality-of-service reservations is accomplished using the
../data/rfc/rfc5977.txt: Authentication, Authorization, and Accounting (AAA) framework and the
../data/rfc/rfc5977.txt- functionality is inherited from the underlying NSIS QoS NSLP, see
../data/rfc/rfc5977.txt- [RFC5974], and not described again in this document. As a technical
../data/rfc/rfc5977.txt- solution mechanism, the Diameter QoS application [RFC5866] may be
../data/rfc/rfc5977.txt- used. The end-to-end reservation request arriving at the Ingress
../data/rfc/rfc5977.txt- node will trigger the authorization procedure with the backend AAA
--
../data/rfc/rfc6041.txt- 4.1.5. QoS Capabilities Exchange and Configuration .........7
../data/rfc/rfc6041.txt- 4.1.6. Security Exchange ...................................7
../data/rfc/rfc6041.txt- 4.1.7. Filtering Exchange and Firewalls ....................7
../data/rfc/rfc6041.txt- 4.1.8. Encapsulation/Tunneling Exchange ....................7
../data/rfc/rfc6041.txt- 4.1.9. NAT and Application-Level Gateways ..................7
../data/rfc/rfc6041.txt: 4.1.10. Measurement and Accounting .........................7
../data/rfc/rfc6041.txt- 4.1.11. Diagnostics ........................................8
../data/rfc/rfc6041.txt- 4.1.12. Redundancy and Failover ............................8
../data/rfc/rfc6041.txt- 4.2. CE-FE Link Capability ......................................8
../data/rfc/rfc6041.txt- 4.3. CE/FE Locality .............................................8
../data/rfc/rfc6041.txt- 5. Security Considerations .........................................9
--
../data/rfc/rfc6041.txt-
../data/rfc/rfc6041.txt- o Encapsulation/Tunneling Exchange
../data/rfc/rfc6041.txt-
../data/rfc/rfc6041.txt- o NAT and Application-Level Gateways
../data/rfc/rfc6041.txt-
../data/rfc/rfc6041.txt: o Measurement and Accounting
../data/rfc/rfc6041.txt-
../data/rfc/rfc6041.txt- o Diagnostics
../data/rfc/rfc6041.txt-
../data/rfc/rfc6041.txt- o CE Redundancy or CE Failover
../data/rfc/rfc6041.txt-
--
../data/rfc/rfc6041.txt- ForCES may be used to exchange configuration information for Network
../data/rfc/rfc6041.txt- Address Translators. Whilst ForCES is not specifically designed for
../data/rfc/rfc6041.txt- the configuration of application-level gateway functionality, this
../data/rfc/rfc6041.txt- may be in scope for some types of application-level gateways.
../data/rfc/rfc6041.txt-
../data/rfc/rfc6041.txt:4.1.10. Measurement and Accounting
../data/rfc/rfc6041.txt-
../data/rfc/rfc6041.txt- ForCES may be used to exchange configuration information regarding
../data/rfc/rfc6041.txt: traffic measurement and accounting functionality. In this area,
../data/rfc/rfc6041.txt- ForCES may overlap somewhat with functionality provided by network
../data/rfc/rfc6041.txt- management mechanisms such as the Simple Network Management Protocol
../data/rfc/rfc6041.txt- (SNMP). In some cases, ForCES may be used to convey information to
../data/rfc/rfc6041.txt- the CE to be reported externally using SNMP. A further discussion of
../data/rfc/rfc6041.txt- this capability is covered in Section 6 of this document.
--
../data/rfc/rfc2058.txt-1. Introduction
../data/rfc/rfc2058.txt-
../data/rfc/rfc2058.txt- Managing dispersed serial line and modem pools for large numbers of
../data/rfc/rfc2058.txt- users can create the need for significant administrative support.
../data/rfc/rfc2058.txt- Since modem pools are by definition a link to the outside world, they
../data/rfc/rfc2058.txt: require careful attention to security, authorization and accounting.
../data/rfc/rfc2058.txt- This can be best achieved by managing a single "database" of users,
../data/rfc/rfc2058.txt- which allows for authentication (verifying user name and password) as
../data/rfc/rfc2058.txt- well as configuration information detailing the type of service to
../data/rfc/rfc2058.txt- deliver to the user (for example, SLIP, PPP, telnet, rlogin).
../data/rfc/rfc2058.txt-
--
../data/rfc/rfc2058.txt- RADIUS Codes (decimal) are assigned as follows:
../data/rfc/rfc2058.txt-
../data/rfc/rfc2058.txt- 1 Access-Request
../data/rfc/rfc2058.txt- 2 Access-Accept
../data/rfc/rfc2058.txt- 3 Access-Reject
../data/rfc/rfc2058.txt: 4 Accounting-Request
../data/rfc/rfc2058.txt: 5 Accounting-Response
../data/rfc/rfc2058.txt- 11 Access-Challenge
../data/rfc/rfc2058.txt- 12 Status-Server (experimental)
../data/rfc/rfc2058.txt- 13 Status-Client (experimental)
../data/rfc/rfc2058.txt- 255 Reserved
../data/rfc/rfc2058.txt-
../data/rfc/rfc2058.txt: Codes 4 and 5 will be covered in the RADIUS Accounting document [9],
../data/rfc/rfc2058.txt- and are not further mentioned here. Codes 12 and 13 are reserved for
../data/rfc/rfc2058.txt- possible use, but are not further mentioned here.
../data/rfc/rfc2058.txt-
../data/rfc/rfc2058.txt-Identifier
../data/rfc/rfc2058.txt-
--
../data/rfc/rfc2058.txt- In the section below on "Attributes" where the text refers to which
../data/rfc/rfc2058.txt- packets an attribute is allowed in, only packets with Codes 1, 2, 3
../data/rfc/rfc2058.txt- and 11 and attributes defined in this document are covered in this
../data/rfc/rfc2058.txt- document. A summary table is provided at the end of the "Attributes"
../data/rfc/rfc2058.txt- section. To determine which Attributes are allowed in packets with
../data/rfc/rfc2058.txt: codes 4 and 5 refer to the RADIUS Accounting document [9].
../data/rfc/rfc2058.txt-
../data/rfc/rfc2058.txt-4. Packet Types
../data/rfc/rfc2058.txt-
../data/rfc/rfc2058.txt- The RADIUS Packet type is determined by the Code field in the first
../data/rfc/rfc2058.txt- octet of the Packet.
--
../data/rfc/rfc2058.txt- 35 Login-LAT-Node
../data/rfc/rfc2058.txt- 36 Login-LAT-Group
../data/rfc/rfc2058.txt- 37 Framed-AppleTalk-Link
../data/rfc/rfc2058.txt- 38 Framed-AppleTalk-Network
../data/rfc/rfc2058.txt- 39 Framed-AppleTalk-Zone
../data/rfc/rfc2058.txt: 40-59 (reserved for accounting)
../data/rfc/rfc2058.txt- 60 CHAP-Challenge
../data/rfc/rfc2058.txt- 61 NAS-Port-Type
../data/rfc/rfc2058.txt- 62 Port-Limit
../data/rfc/rfc2058.txt- 63 Login-LAT-Port
../data/rfc/rfc2058.txt-
--
../data/rfc/rfc2058.txt-
../data/rfc/rfc2058.txt- Description
../data/rfc/rfc2058.txt-
../data/rfc/rfc2058.txt- This Attribute is available to be sent by the server to the client
../data/rfc/rfc2058.txt- in an Access-Accept and should be sent unmodified by the client to
../data/rfc/rfc2058.txt: the accounting server as part of the Accounting-Request packet if
../data/rfc/rfc2058.txt: accounting is supported. No interpretation by the client should
../data/rfc/rfc2058.txt- be made.
../data/rfc/rfc2058.txt-
../data/rfc/rfc2058.txt-
../data/rfc/rfc2058.txt-
../data/rfc/rfc2058.txt-
--
../data/rfc/rfc2058.txt- [8] Galvin, J., McCloghrie, K., and J. Davin, "SNMP Security
../data/rfc/rfc2058.txt- Protocols", RFC 1352, Trusted Information Systems, Inc., Hughes
../data/rfc/rfc2058.txt- LAN Systems, Inc., MIT Laboratory for Computer Science, July
../data/rfc/rfc2058.txt- 1992.
../data/rfc/rfc2058.txt-
../data/rfc/rfc2058.txt: [9] Rigney, C., "RADIUS Accounting", RFC 2059, January 1997.
../data/rfc/rfc2058.txt-
../data/rfc/rfc2058.txt-Acknowledgments
../data/rfc/rfc2058.txt-
../data/rfc/rfc2058.txt- RADIUS was originally developed by Livingston Enterprises for their
../data/rfc/rfc2058.txt- PortMaster series of Network Access Servers.
--
../data/rfc/rfc5920.txt- interworking, there is a good discussion on security for management
../data/rfc/rfc5920.txt- interfaces to Network Elements [OIF-Sec-Mag].
../data/rfc/rfc5920.txt-
../data/rfc/rfc5920.txt- Network elements typically have one or more (in some cases many)
../data/rfc/rfc5920.txt- Operation and Management interfaces used for network management,
../data/rfc/rfc5920.txt: billing and accounting, configuration, maintenance, and other
../data/rfc/rfc5920.txt- administrative activities.
../data/rfc/rfc5920.txt-
../data/rfc/rfc5920.txt- Remote access to a network element through these Operation and
../data/rfc/rfc5920.txt- Management interfaces is frequently a requirement. Securing the
../data/rfc/rfc5920.txt- control protocols while leaving these Operation and Management
--
../data/rfc/rfc5380.txt-
../data/rfc/rfc5380.txt-RFC 5380 HMIPv6 October 2008
../data/rfc/rfc5380.txt-
../data/rfc/rfc5380.txt-
../data/rfc/rfc5380.txt- Hence, EAP can be used with IKEv2 to leverage the Authentication,
../data/rfc/rfc5380.txt: Authorization, and Accounting (AAA) infrastructure to bootstrap the
../data/rfc/rfc5380.txt- SA between the mobile node and the MAP. Such a mechanism is useful
../data/rfc/rfc5380.txt- in scenarios where an administrator wishes to avoid the configuration
../data/rfc/rfc5380.txt- and management of certificates on mobile nodes. A MAP MAY support
../data/rfc/rfc5380.txt- the use of EAP over IKEv2.
../data/rfc/rfc5380.txt-
--
../data/rfc/rfc501.txt- Un-Muddling "Free File Transfer"
../data/rfc/rfc501.txt-
../data/rfc/rfc501.txt- As the ARPA Network begin to mature, we find ourselves addressing
../data/rfc/rfc501.txt- issues and concepts deliberately put off and left untouched at
../data/rfc/rfc501.txt- earlier stages of Network development. Among the issues now coming
../data/rfc/rfc501.txt: to the fore are access control, user authentication, and accounting.
../data/rfc/rfc501.txt- These issues arise immediately out of efforts to develop uniform
../data/rfc/rfc501.txt- methods for providing limited "free" access to the File Transfer
../data/rfc/rfc501.txt- Servers of the host systems, to meet user needs for mail transmission
../data/rfc/rfc501.txt- and similar services.
../data/rfc/rfc501.txt-
--
../data/rfc/rfc501.txt- security, but on which the user has no access privileges".
../data/rfc/rfc501.txt- Unfortunately, beginning with the first paragraph of the RFC, the
../data/rfc/rfc501.txt- notions of access controls on files (examples of protection
../data/rfc/rfc501.txt- mechanisms), and control of access to the system (user
../data/rfc/rfc501.txt- authentication) are thoroughly muddled. In addition, he makes
../data/rfc/rfc501.txt: sweeping assumptions about the nature and use of accounting
../data/rfc/rfc501.txt- mechanisms and accounts at server sites. RFC 487 also has buried
../data/rfc/rfc501.txt- deep within it assumptions about the nature of the access control and
../data/rfc/rfc501.txt- user authentication aspects of File Transfer Server implementations.
../data/rfc/rfc501.txt-
../data/rfc/rfc501.txt- What's needed at this juncture, of course, is a lucid discussion of
--
../data/rfc/rfc501.txt- the remainder of this RFC. What you will find is perhaps enough of a
../data/rfc/rfc501.txt- discussion to un-muddle that which RFC 487 has muddled; the rest will
../data/rfc/rfc501.txt- have to come down the pike at a later time.
../data/rfc/rfc501.txt-
../data/rfc/rfc501.txt- In many systems, mechanisms which control access to the system,
../data/rfc/rfc501.txt: mechanism which control access to files, and accounting mechanisms
../data/rfc/rfc501.txt- all mesh at the moment at which a prospective user of the system is
../data/rfc/rfc501.txt- authenticated: the system has checked his user-name, password,
../data/rfc/rfc501.txt-
../data/rfc/rfc501.txt-
../data/rfc/rfc501.txt-
--
../data/rfc/rfc501.txt- "Network services" account. Mechanisms for accomplishing this are
../data/rfc/rfc501.txt- presented in RFC 491. [3]
../data/rfc/rfc501.txt-
../data/rfc/rfc501.txt- RFC 487 matter-of-factly suggests that retrieval of files in "system"
../data/rfc/rfc501.txt- directories should be charged to "overhead". Here too, some broad
../data/rfc/rfc501.txt: assumptions are made about the nature of accounting mechanisms and
../data/rfc/rfc501.txt- accounts at server sites. In addition, an undesirable loss of
../data/rfc/rfc501.txt- generality is imposed upon the File Transfer Server: It is now
../data/rfc/rfc501.txt- required to have the capability of distinguishing the pathnames of
../data/rfc/rfc501.txt- "system" files from those of "user" files. In a number of systems,
../data/rfc/rfc501.txt- there is no syntactic distinction between the two, and the same
--
../data/rfc/rfc501.txt- users. I don't think many people in the Network community would
../data/rfc/rfc501.txt- consider the actual (as opposed to charged) CPU time spent
../data/rfc/rfc501.txt- transferring a file to be negligible. Certainly, if a system is a
../data/rfc/rfc501.txt- very popular or busy one from a Network standpoint, the cumulative
../data/rfc/rfc501.txt- CPU time spent on "free" file transfers, viewed at the end of an
../data/rfc/rfc501.txt: accounting period (a week? a month? a year?) will not be negligible!
../data/rfc/rfc501.txt-
../data/rfc/rfc501.txt- In this RFC, I've picked apart Bob Bressler's RFC 487, mostly because
../data/rfc/rfc501.txt- of its confusion of several distinct (although related) issues, and
../data/rfc/rfc501.txt- the implementation assumptions it contains which conflict with (or
../data/rfc/rfc501.txt- badly bend out of shape) mechanisms and design philosophies existing
--
../data/rfc/rfc2900.txt-WEBDAV HTTP Extensions for Distributed Authoring -- WEBDAV 2518
../data/rfc/rfc2900.txt-ATM-MIBMAN Definitions of Managed Objects for ATM Management 2515
../data/rfc/rfc2900.txt-ATM-TC-OID Definitions of Textual Conventions and OBJECT- 2514
../data/rfc/rfc2900.txt- IDENTITIES for ATM Management
../data/rfc/rfc2900.txt--------- Managed Objects for Controlling the Collection 2513
../data/rfc/rfc2900.txt: and Storage of Accounting Information for
../data/rfc/rfc2900.txt- Connection-Oriented Networks
../data/rfc/rfc2900.txt:-------- Accounting Information for ATM Networks 2512
../data/rfc/rfc2900.txt-X.509-CRMF Internet X.509 Certificate Request Message Format 2511
../data/rfc/rfc2900.txt-PKICMP Internet X.509 Public Key Infrastructure Certificate 2510
../data/rfc/rfc2900.txt- Management Protocols
../data/rfc/rfc2900.txt-IPCOM-PPP IP Header Compression over PPP 2509
../data/rfc/rfc2900.txt--------- Compressing IP/UDP/RTP Headers for Low-Speed Serial 2508
--
../data/rfc/rfc5351.txt- partially overlap with grid computing/high-performance
../data/rfc/rfc5351.txt- computing. However, the scope of both areas is completely
../data/rfc/rfc5351.txt- different: grid and high-performance computing also cover
../data/rfc/rfc5351.txt- topics like managing different administrative domains, data
../data/rfc/rfc5351.txt- locking and synchronization, inter-session communication, and
../data/rfc/rfc5351.txt: resource accounting for powerful computation services, but the
../data/rfc/rfc5351.txt- intention of RSerPool is simply a lightweight realization of
../data/rfc/rfc5351.txt- load distribution and session management. In particular, these
../data/rfc/rfc5351.txt- functionalities are intended to be used on
../data/rfc/rfc5351.txt-
../data/rfc/rfc5351.txt-
--
../data/rfc/rfc2998.txt- 2. Only a small number of hosts currently generate RSVP signaling.
../data/rfc/rfc2998.txt- While this number is expected to grow dramatically, many
../data/rfc/rfc2998.txt- applications may never generate RSVP signaling.
../data/rfc/rfc2998.txt-
../data/rfc/rfc2998.txt- 3. The necessary policy control mechanisms -- access control,
../data/rfc/rfc2998.txt: authentication, and accounting -- have only recently become
../data/rfc/rfc2998.txt- available [17].
../data/rfc/rfc2998.txt-
../data/rfc/rfc2998.txt-1.3 Diffserv
../data/rfc/rfc2998.txt-
../data/rfc/rfc2998.txt- In contrast to the per-flow orientation of RSVP, Diffserv networks
--
../data/rfc/rfc4372.txt- Chargeable-User-Identity in order to demonstrate willingness to pay
../data/rfc/rfc4372.txt- or otherwise limit the potential for fraud.
../data/rfc/rfc4372.txt-
../data/rfc/rfc4372.txt- This implies that a unique identity provided by the home network
../data/rfc/rfc4372.txt- should be able to be conveyed to all parties involved in the roaming
../data/rfc/rfc4372.txt: transaction for correlating the authentication and accounting
../data/rfc/rfc4372.txt- packets.
../data/rfc/rfc4372.txt-
../data/rfc/rfc4372.txt- Providing a unique identity, Chargeable-User-Identity (CUI), to
../data/rfc/rfc4372.txt- intermediaries, is necessary to fulfill certain business needs. This
../data/rfc/rfc4372.txt- should not undermine the anonymity of the user. The mechanism
--
../data/rfc/rfc4372.txt-
../data/rfc/rfc4372.txt- - On the use of RADIUS Class(25) attribute:
../data/rfc/rfc4372.txt-
../data/rfc/rfc4372.txt- [RFC2865] states: "This Attribute is available to be sent by the
../data/rfc/rfc4372.txt- server to the client in an Access-Accept packet and SHOULD be sent
../data/rfc/rfc4372.txt: unmodified by the client to the accounting server as part of the
../data/rfc/rfc4372.txt: Accounting-Request packet if accounting is supported. The client
../data/rfc/rfc4372.txt- MUST NOT interpret the attribute locally." So RADIUS clients or
../data/rfc/rfc4372.txt- intermediaries MUST NOT interpret the Class(25) attribute, which
../data/rfc/rfc4372.txt- precludes determining whether it contains a CUI. Additionally,
../data/rfc/rfc4372.txt- there could be multiple class attributes in a RADIUS packet, and
../data/rfc/rfc4372.txt- since the contents of Class(25) attribute is not to be interpreted
--
../data/rfc/rfc4372.txt-RFC 4372 Chargeable User Identity January 2006
../data/rfc/rfc4372.txt-
../data/rfc/rfc4372.txt-
../data/rfc/rfc4372.txt- included within an Access-Accept packet. The result is that when
../data/rfc/rfc4372.txt- a User-Name(1) attribute is sent in an Access-Accept packet, it is
../data/rfc/rfc4372.txt: possible that the Access-Request packet and Accounting-Request
../data/rfc/rfc4372.txt- packets will follow different paths. Where this outcome is
../data/rfc/rfc4372.txt- undesirable, the RADIUS client should use the original
../data/rfc/rfc4372.txt: User-Name(1) in accounting packets. Therefore, another mechanism
../data/rfc/rfc4372.txt- is required to convey a CUI within an Access-Accept packet to the
../data/rfc/rfc4372.txt: RADIUS client, so that the CUI can be included in the accounting
../data/rfc/rfc4372.txt- packets.
../data/rfc/rfc4372.txt-
../data/rfc/rfc4372.txt- The CUI attribute provides a solution to the above problems and
../data/rfc/rfc4372.txt- avoids overloading RADIUS User-Name(1) attribute or changing the
../data/rfc/rfc4372.txt- usage of existing RADIUS Class(25) attribute. The CUI therefore
--
../data/rfc/rfc4372.txt- document are to be interpreted as described in [RFC2119].
../data/rfc/rfc4372.txt-
../data/rfc/rfc4372.txt- The following acronyms are used:
../data/rfc/rfc4372.txt-
../data/rfc/rfc4372.txt- 3GPP - Third Generation Partnership Project
../data/rfc/rfc4372.txt: AAA - Authentication, Authorization, and Accounting
../data/rfc/rfc4372.txt- AKA - Authentication and Key Agreement
../data/rfc/rfc4372.txt- CUI - Chargeable-User-Identity
../data/rfc/rfc4372.txt- GSMA - GSM Association
../data/rfc/rfc4372.txt- IRAP - International Roaming Access Protocols Program
../data/rfc/rfc4372.txt- NAS - Network Access Server
--
../data/rfc/rfc4372.txt- a RADIUS client that requested the CUI attribute, then the
../data/rfc/rfc4372.txt- Access-Accept packet MAY be treated as an Access-Reject.
../data/rfc/rfc4372.txt-
../data/rfc/rfc4372.txt- If the CUI was included in an Access-Accept packet, RADIUS clients
../data/rfc/rfc4372.txt- supporting the CUI attribute MUST ensure that the CUI attribute
../data/rfc/rfc4372.txt: appears in the RADIUS Accounting-Request (Start, Interim, and Stop).
../data/rfc/rfc4372.txt- This requirement applies regardless of whether the RADIUS client
../data/rfc/rfc4372.txt- requested the CUI attribute.
../data/rfc/rfc4372.txt-
../data/rfc/rfc4372.txt- RFC 2865 includes the following statements about behaviors of RADIUS
../data/rfc/rfc4372.txt- client and server with respect to unsupported attributes:
--
../data/rfc/rfc4372.txt- initial authentication or during re-authentication.
../data/rfc/rfc4372.txt-
../data/rfc/rfc4372.txt- A NAS that requested the CUI during re-authentication by including
../data/rfc/rfc4372.txt- the CUI in the Access-Request will receive the CUI in the
../data/rfc/rfc4372.txt- Access-Accept. The NAS MUST include the value of that CUI in all
../data/rfc/rfc4372.txt: Accounting Messages.
../data/rfc/rfc4372.txt-
../data/rfc/rfc4372.txt-2.2. CUI Attribute
../data/rfc/rfc4372.txt-
../data/rfc/rfc4372.txt- A summary of the RADIUS CUI attribute is given below.
../data/rfc/rfc4372.txt-
--
../data/rfc/rfc4372.txt-3. Attribute Table
../data/rfc/rfc4372.txt-
../data/rfc/rfc4372.txt- The following table provides a guide to which attribute(s) may be
../data/rfc/rfc4372.txt- found in which kinds of packets, and in what quantity.
../data/rfc/rfc4372.txt-
../data/rfc/rfc4372.txt: Request Accept Reject Challenge Accounting # Attribute
../data/rfc/rfc4372.txt- Request
../data/rfc/rfc4372.txt- 0-1 0-1 0 0 0-1 89 Chargeable-User-Identity
../data/rfc/rfc4372.txt-
../data/rfc/rfc4372.txt- Note: If the Access-Accept packet contains CUI, then the NAS MUST
../data/rfc/rfc4372.txt: include the CUI in Accounting Requests (Start, Interim, and Stop)
../data/rfc/rfc4372.txt- packets.
../data/rfc/rfc4372.txt-
../data/rfc/rfc4372.txt-4. Diameter Consideration
../data/rfc/rfc4372.txt-
../data/rfc/rfc4372.txt- Diameter needs to define an identical attribute with the same Type
--
../data/rfc/rfc4372.txt- The RADIUS entities (RADIUS proxies and clients) outside the home
../data/rfc/rfc4372.txt- network MUST NOT modify the CUI or insert a CUI in an Access-Accept.
../data/rfc/rfc4372.txt- However, there is no way to detect or prevent this.
../data/rfc/rfc4372.txt-
../data/rfc/rfc4372.txt- Attempting theft of service, a man-in-the-middle may try to insert,
../data/rfc/rfc4372.txt: modify, or remove the CUI in the Access-Accept packets and Accounting
../data/rfc/rfc4372.txt: packets. However, RADIUS Access-Accept and Accounting packets
../data/rfc/rfc4372.txt- already provide integrity protection.
../data/rfc/rfc4372.txt-
../data/rfc/rfc4372.txt-
../data/rfc/rfc4372.txt-
../data/rfc/rfc4372.txt-
--
../data/rfc/rfc4372.txt-
../data/rfc/rfc4372.txt- [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
../data/rfc/rfc4372.txt- "Remote Authentication Dial In User Service (RADIUS)",
../data/rfc/rfc4372.txt- RFC 2865, June 2000.
../data/rfc/rfc4372.txt-
../data/rfc/rfc4372.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc4372.txt-
../data/rfc/rfc4372.txt- [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
../data/rfc/rfc4372.txt- "Diameter Network Access Server Application", RFC 4005,
../data/rfc/rfc4372.txt- August 2005.
../data/rfc/rfc4372.txt-
--
../data/rfc/rfc5749.txt- specific root key (DSUSRK) that has been derived from an Extended
../data/rfc/rfc5749.txt- Master Session Key (EMSK) hierarchy previously established between
../data/rfc/rfc5749.txt- the EAP server and an EAP peer. This document defines a template for
../data/rfc/rfc5749.txt- a key distribution exchange (KDE) protocol that can distribute these
../data/rfc/rfc5749.txt- different types of root keys using a AAA (Authentication,
../data/rfc/rfc5749.txt: Authorization, and Accounting) protocol and discusses its security
../data/rfc/rfc5749.txt- requirements. The described protocol template does not specify
../data/rfc/rfc5749.txt- message formats, data encoding, or other implementation details. It
../data/rfc/rfc5749.txt- thus needs to be instantiated with a specific protocol (e.g., RADIUS
../data/rfc/rfc5749.txt- or Diameter) before it can be used.
../data/rfc/rfc5749.txt-
--
../data/rfc/rfc5749.txt- document, a server delivering root keys is referred to as a Key
../data/rfc/rfc5749.txt- Delivering Server (KDS), and a server authorized to request and
../data/rfc/rfc5749.txt- receive root keys from a KDS is referred to as a Key Requesting
../data/rfc/rfc5749.txt- Server (KRS). The Key Distribution Exchange (KDE) mechanism defined
../data/rfc/rfc5749.txt- in this document runs over a AAA (Authentication, Authorization, and
../data/rfc/rfc5749.txt: Accounting) protocol, e.g., RADIUS ([RFC2865], [RFC3579]) or Diameter
../data/rfc/rfc5749.txt- [RFC3588], and has several variants depending on the type of key that
../data/rfc/rfc5749.txt- is requested and delivered (i.e., DRSK, USRK, or DSUSRK). The
../data/rfc/rfc5749.txt-
../data/rfc/rfc5749.txt-
../data/rfc/rfc5749.txt-
--
../data/rfc/rfc5749.txt- document are to be interpreted as described in [RFC2119].
../data/rfc/rfc5749.txt-
../data/rfc/rfc5749.txt- The following acronyms are used.
../data/rfc/rfc5749.txt-
../data/rfc/rfc5749.txt- AAA
../data/rfc/rfc5749.txt: Authentication, Authorization and Accounting. AAA protocols with
../data/rfc/rfc5749.txt- EAP support include RADIUS ([RFC2865], [RFC3579]) and Diameter
../data/rfc/rfc5749.txt- [RFC3588].
../data/rfc/rfc5749.txt-
../data/rfc/rfc5749.txt- USRK
../data/rfc/rfc5749.txt- Usage-Specific Root Key. A root key that is derived from the
--
../data/rfc/rfc960.txt- 1-149 Unassigned [JBP]
../data/rfc/rfc960.txt- 150 Xerox NS IDP [129,LLG]
../data/rfc/rfc960.txt- 151 Unassigned [JBP]
../data/rfc/rfc960.txt- 152 PARC Universal Protocol [15,HGM]
../data/rfc/rfc960.txt- 153 TIP Status Reporting [JGH]
../data/rfc/rfc960.txt: 154 TIP Accounting [JGH]
../data/rfc/rfc960.txt- 155 Internet Protocol [regular] [39,92,JBP]
../data/rfc/rfc960.txt- 156-158 Internet Protocol [experimental] [39,92,JBP]
../data/rfc/rfc960.txt- 159 Figleaf Link [JBW1]
../data/rfc/rfc960.txt- 160-194 Unassigned [JBP]
../data/rfc/rfc960.txt- 195 ISO-IP [58,RXM]
--
../data/rfc/rfc5974.txt- Authorization:
../data/rfc/rfc5974.txt-
../data/rfc/rfc5974.txt- The QoS NSLP must assure that the network is protected against
../data/rfc/rfc5974.txt- theft-of-service by offering mechanisms to authorize the QoS
../data/rfc/rfc5974.txt- reservation requester. A user requesting a QoS reservation might
../data/rfc/rfc5974.txt: want proper resource accounting and protection against spoofing
../data/rfc/rfc5974.txt- and other security vulnerabilities that lead to denial of service
../data/rfc/rfc5974.txt- and financial loss. In many cases, authorization is based on the
../data/rfc/rfc5974.txt- authenticated identity. The authorization solution must provide
../data/rfc/rfc5974.txt- guarantees that replay attacks are either not possible or limited
../data/rfc/rfc5974.txt- to a certain extent. Authorization can also be based on traits
--
../data/rfc/rfc5974.txt- .... Communication to the end host
../data/rfc/rfc5974.txt-
../data/rfc/rfc5974.txt- Figure 16: New Jersey Turnpike Model
../data/rfc/rfc5974.txt-
../data/rfc/rfc5974.txt- The model shown in Figure 16 uses peer-to-peer relationships between
../data/rfc/rfc5974.txt: different administrative domains as a basis for accounting and
../data/rfc/rfc5974.txt- charging. As mentioned above, based on the peering relationship, a
../data/rfc/rfc5974.txt- chain-of-trust is established. There are several issues that come to
../data/rfc/rfc5974.txt- mind when considering this type of model:
../data/rfc/rfc5974.txt-
../data/rfc/rfc5974.txt- o The model allows authorization on a request basis or on a per-
--
../data/rfc/rfc5974.txt- exchanged between the different networks are then also subject to
../data/rfc/rfc5974.txt- authentication and authorization. However, the authenticated entity
../data/rfc/rfc5974.txt- is thereby the neighboring network and not the end host.
../data/rfc/rfc5974.txt-
../data/rfc/rfc5974.txt- The New Jersey Turnpike model is attractive because of its
../data/rfc/rfc5974.txt: simplicity. S. Shenker, et al. [shenker] discuss various accounting
../data/rfc/rfc5974.txt- implications and introduced the edge pricing model. The edge pricing
../data/rfc/rfc5974.txt- model shows similarity to the model described in this section, with
../data/rfc/rfc5974.txt- the exception that mobility and the security implications are not
../data/rfc/rfc5974.txt- addressed.
../data/rfc/rfc5974.txt-
--
../data/rfc/rfc5974.txt- o bypassing_type: it defines if a QNE bypasses end-to-end messages
../data/rfc/rfc5974.txt- or not
../data/rfc/rfc5974.txt-
../data/rfc/rfc5974.txt-Appendix B. Glossary
../data/rfc/rfc5974.txt-
../data/rfc/rfc5974.txt: AAA: Authentication, Authorization, and Accounting
../data/rfc/rfc5974.txt-
../data/rfc/rfc5974.txt- EAP: Extensible Authentication Protocol
../data/rfc/rfc5974.txt-
../data/rfc/rfc5974.txt- MRI: Message Routing Information (see [RFC5971])
../data/rfc/rfc5974.txt-
--
../data/rfc/rfc189.txt- CAN (CANCEL) (a) On an output channel, CAN causes the rest of the
../data/rfc/rfc189.txt- output in the sysout data set currently being
../data/rfc/rfc189.txt- transmitted to be omitted. Alternatively, may
../data/rfc/rfc189.txt- omit the rest of the sysout data sets for the job
../data/rfc/rfc189.txt- currently being transmitted; however, the remain-
../data/rfc/rfc189.txt: ing system and accounting messages will be sent.
../data/rfc/rfc189.txt-
../data/rfc/rfc189.txt-
../data/rfc/rfc189.txt-
../data/rfc/rfc189.txt-
../data/rfc/rfc189.txt-
--
../data/rfc/rfc122.txt-
../data/rfc/rfc122.txt-I. Preface
../data/rfc/rfc122.txt-
../data/rfc/rfc122.txt- UCSB will provide file storage for Network users. UCSB's Simple
../data/rfc/rfc122.txt- Minded File System (SMFS) is addressed as socket number X'401', site
../data/rfc/rfc122.txt: 3. No accounting parameters are required. This document is intended
../data/rfc/rfc122.txt- to provide programmers with the information necessary to communicate
../data/rfc/rfc122.txt- with SMFS which conducts all Network transactions trough its NCP
../data/rfc/rfc122.txt- which operates under the Host-Host protocol of August 3, 1970.*
../data/rfc/rfc122.txt-
../data/rfc/rfc122.txt-II. Implementation
--
../data/rfc/rfc6677.txt- the current Extensible Authentication Protocol (EAP) architecture
../data/rfc/rfc6677.txt- [RFC3748] when used in pass-through authenticator mode. Here, a
../data/rfc/rfc6677.txt- Network Access Server (NAS), or pass-through authenticator, may
../data/rfc/rfc6677.txt- represent one set of information (e.g., network identity,
../data/rfc/rfc6677.txt- capabilities, configuration, etc) to the backend Authentication,
../data/rfc/rfc6677.txt: Authorization, and Accounting (AAA) infrastructure, while
../data/rfc/rfc6677.txt- representing contrary information to EAP peers. Another possibility
../data/rfc/rfc6677.txt- is that the same false information could be provided to both the EAP
../data/rfc/rfc6677.txt- peer and EAP server by the NAS. A "lying" entity can also be located
../data/rfc/rfc6677.txt- anywhere on the AAA path between the NAS and the EAP server.
../data/rfc/rfc6677.txt-
--
../data/rfc/rfc6677.txt-
../data/rfc/rfc6677.txt- A new RADIUS attribute is defined to carry information on which EAP
../data/rfc/rfc6677.txt- lower layer is used for this EAP authentication. This attribute
../data/rfc/rfc6677.txt- provides information relating to the lower layer over which EAP is
../data/rfc/rfc6677.txt- transported. This attribute MAY be sent by the NAS to the RADIUS
../data/rfc/rfc6677.txt: server in an Access-Request or an Accounting-Request packet. A
../data/rfc/rfc6677.txt- summary of the EAP-Lower-Layer attribute format is shown below. The
../data/rfc/rfc6677.txt- fields are transmitted from left to right.
../data/rfc/rfc6677.txt-
../data/rfc/rfc6677.txt- 0 1 2 3
../data/rfc/rfc6677.txt- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
--
../data/rfc/rfc4081.txt- given set of QoS parameters.
../data/rfc/rfc4081.txt-
../data/rfc/rfc4081.txt- In today's networks, non-repudiation is not provided. Therefore, it
../data/rfc/rfc4081.txt- might be difficult to introduce with NSIS signaling. The user has to
../data/rfc/rfc4081.txt- trust the network operator to meter the traffic correctly, to collect
../data/rfc/rfc4081.txt: and merge accounting data, and to ensure that no unforeseen problems
../data/rfc/rfc4081.txt-
../data/rfc/rfc4081.txt-
../data/rfc/rfc4081.txt-
../data/rfc/rfc4081.txt-
../data/rfc/rfc4081.txt-
--
../data/rfc/rfc4081.txt- Network elements within a domain (intra-domain) experience a
../data/rfc/rfc4081.txt- different trust relationship with regard to the security protection
../data/rfc/rfc4081.txt- of signaling messages from that of edge NSIS entities. It is assumed
../data/rfc/rfc4081.txt- that edge NSIS entities are responsible for performing cryptographic
../data/rfc/rfc4081.txt- processing (authentication, integrity and replay protection,
../data/rfc/rfc4081.txt: authorization, and accounting) for signaling messages arriving from
../data/rfc/rfc4081.txt- the outside. This prevents unprotected signaling messages from
../data/rfc/rfc4081.txt- appearing within the internal network. If, however, an adversary
../data/rfc/rfc4081.txt- manages to take over an edge router, then the security of the entire
../data/rfc/rfc4081.txt- network is compromised. An adversary is then able to launch a number
../data/rfc/rfc4081.txt- of attacks, including denial of service; integrity violations; replay
--
../data/rfc/rfc7015.txt- determined by the maximum active timeout.
../data/rfc/rfc7015.txt-
../data/rfc/rfc7015.txt- In certain circumstances, additional delay at the original Exporter
../data/rfc/rfc7015.txt- may cause an IAP to close an interval before the last Original
../data/rfc/rfc7015.txt- Flow(s) accountable to the interval arrives. In this case, the IAP
../data/rfc/rfc7015.txt: MAY drop the late Original Flow(s). Accounting of Flows lost at an
../data/rfc/rfc7015.txt- Intermediate Process due to such issues is covered in
../data/rfc/rfc7015.txt- [IPFIX-MED-PROTO].
../data/rfc/rfc7015.txt-
../data/rfc/rfc7015.txt-6.3. Considerations for Aggregation of Sampled Flows
../data/rfc/rfc7015.txt-
--
../data/rfc/rfc7015.txt- described in Section 5.1.1, the Exporting Process MAY export an
../data/rfc/rfc7015.txt- Aggregate Counter Distribution Option Record for each Template
../data/rfc/rfc7015.txt- describing Aggregated Flow records; this Options Template is
../data/rfc/rfc7015.txt- described below. It uses the valueDistributionMethod Information
../data/rfc/rfc7015.txt- Element, also defined below. Since, in many cases, distribution is
../data/rfc/rfc7015.txt: simple, accounting the counters from Contributing Flows to the first
../data/rfc/rfc7015.txt- Interval to which they contribute, this is the default situation, for
../data/rfc/rfc7015.txt- which no Aggregate Counter Distribution Record is necessary;
../data/rfc/rfc7015.txt- Aggregate Counter Distribution Records are only applicable in more
../data/rfc/rfc7015.txt- exotic situations, such as using an Aggregation Interval smaller than
../data/rfc/rfc7015.txt- the durations of Original Flows.
--
../data/rfc/rfc5253.txt-9. Manageability Considerations
../data/rfc/rfc5253.txt-
../data/rfc/rfc5253.txt- Manageability considerations are described in [RFC4847]. In the
../data/rfc/rfc5253.txt- L1VPN Basic Mode, we rely on management systems for various aspects
../data/rfc/rfc5253.txt- of the different service functions, such as fault management,
../data/rfc/rfc5253.txt: configuration and policy management, accounting management,
../data/rfc/rfc5253.txt- performance management, and security management (as described in
../data/rfc/rfc5253.txt- Section 8).
../data/rfc/rfc5253.txt-
../data/rfc/rfc5253.txt- In order to support various management functionalities, MIB modules
../data/rfc/rfc5253.txt- need to be supported. In particular, the GMPLS TE MIB (GMPLS-TE-STD-
--
../data/rfc/rfc4665.txt- Standard interfaces to manage L2VPN services MUST be provided (e.g.,
../data/rfc/rfc4665.txt- standard SNMP MIB Modules). These interfaces SHOULD provide access
../data/rfc/rfc4665.txt- to configuration, verification and runtime monitoring protocols.
../data/rfc/rfc4665.txt-
../data/rfc/rfc4665.txt- Service management MAY include the TMN 'FCAPS' functionalities, as
../data/rfc/rfc4665.txt: follows: Fault, Configuration, Accounting, Performance, and Security,
../data/rfc/rfc4665.txt- as detailed in [ITU_Y.1311.1].
../data/rfc/rfc4665.txt-
../data/rfc/rfc4665.txt-5.12. Interoperability
../data/rfc/rfc4665.txt-
../data/rfc/rfc4665.txt- Multi-vendor interoperability, which corresponds to similar network
--
../data/rfc/rfc4665.txt- standards-based interfaces (e.g., L2VPN MIB Modules), wherever
../data/rfc/rfc4665.txt- feasible.
../data/rfc/rfc4665.txt-
../data/rfc/rfc4665.txt- The details of service provider management requirements for a Network
../data/rfc/rfc4665.txt- Management System (NMS) in the traditional fault, configuration,
../data/rfc/rfc4665.txt: accounting, performance, and security (FCAPS) management categories
../data/rfc/rfc4665.txt- can be found in [ITU_Y.1311.1].
../data/rfc/rfc4665.txt-
../data/rfc/rfc4665.txt-9. Engineering Requirements
../data/rfc/rfc4665.txt-
../data/rfc/rfc4665.txt- These requirements are driven by implementation characteristics that
--
../data/rfc/rfc7156.txt- statement for PMIPv6 localized routing. Based on the scenarios A11,
../data/rfc/rfc7156.txt- A12, and A21 described in [RFC6279], [RFC6705] specifies the PMIPv6
../data/rfc/rfc7156.txt- localized routing protocol that is used to establish a localized
../data/rfc/rfc7156.txt- routing path between two Mobile Access Gateways in a PMIPv6 domain.
../data/rfc/rfc7156.txt-
../data/rfc/rfc7156.txt: This document describes Authentication, Authorization, and Accounting
../data/rfc/rfc7156.txt- (AAA) support using Diameter [RFC6733] for the authorization
../data/rfc/rfc7156.txt- procedure between the PMIPv6 mobility entities (MAG or LMA) and a AAA
../data/rfc/rfc7156.txt- server within a Proxy Mobile IPv6 domain for localized routing in the
../data/rfc/rfc7156.txt- scenarios A11, A12, and A21 described in [RFC6279].
../data/rfc/rfc7156.txt-
--
../data/rfc/rfc6235.txt- +-----------------------+----------------------------+
../data/rfc/rfc6235.txt-
../data/rfc/rfc6235.txt-4.3.1. Precision Degradation
../data/rfc/rfc6235.txt-
../data/rfc/rfc6235.txt- Precision Degradation is a generalization technique that removes the
../data/rfc/rfc6235.txt: most precise components of a timestamp, accounting for all events
../data/rfc/rfc6235.txt- occurring in each given interval (e.g., one millisecond for
../data/rfc/rfc6235.txt- millisecond level degradation) as simultaneous. This has the effect
../data/rfc/rfc6235.txt- of potentially collapsing many timestamps into one. With this
../data/rfc/rfc6235.txt- technique, time precision is reduced and sequencing may be lost, but
../data/rfc/rfc6235.txt- the information regarding at which time the event occurred is
--
../data/rfc/rfc5692.txt- specified in Section 7.1.1.
../data/rfc/rfc5692.txt-
../data/rfc/rfc5692.txt-8. Public Access Recommendations
../data/rfc/rfc5692.txt-
../data/rfc/rfc5692.txt- In the public access scenario, direct communication between nodes is
../data/rfc/rfc5692.txt: restricted because of security and accounting issues. Figure 4
../data/rfc/rfc5692.txt- depicts the public access scenario.
../data/rfc/rfc5692.txt-
../data/rfc/rfc5692.txt- In this scenario, the AR is connected to a network-side bridge. The
../data/rfc/rfc5692.txt: AR MAY perform security filtering, policing, and accounting of all
../data/rfc/rfc5692.txt- traffic from hosts, e.g., like an NAS (Network Access Server).
../data/rfc/rfc5692.txt-
../data/rfc/rfc5692.txt- If the AR functions as the NAS, all the traffic from SSs SHOULD be
../data/rfc/rfc5692.txt- forwarded to the AR, not bridged at the network-side bridging
../data/rfc/rfc5692.txt- function -- even in the case of traffic between SSs served by the
--
../data/rfc/rfc6421.txt- implementations, crypto-agility may be better defined as the ability
../data/rfc/rfc6421.txt- of RADIUS implementations to automatically negotiate cryptographic
../data/rfc/rfc6421.txt- algorithms for use in RADIUS exchanges, including the algorithms used
../data/rfc/rfc6421.txt- to integrity protect and authenticate RADIUS packets and to hide
../data/rfc/rfc6421.txt- RADIUS attributes. This capability covers all RADIUS message types:
../data/rfc/rfc6421.txt: Access-Request/Response, Accounting-Request/Response, CoA/Disconnect-
../data/rfc/rfc6421.txt- Request/Response, and Status-Server. Negotiation of cryptographic
../data/rfc/rfc6421.txt- algorithms MAY occur within the RADIUS protocol, or within a lower
../data/rfc/rfc6421.txt- layer such as the transport layer.
../data/rfc/rfc6421.txt-
../data/rfc/rfc6421.txt- Proposals MUST NOT introduce generic new capability negotiation
--
../data/rfc/rfc6421.txt-
../data/rfc/rfc6421.txt-4.5. Scope of Work
../data/rfc/rfc6421.txt-
../data/rfc/rfc6421.txt- Crypto-agility solutions MUST apply to all RADIUS packet types,
../data/rfc/rfc6421.txt- including Access-Request, Access-Challenge, Access-Reject,
../data/rfc/rfc6421.txt: Access-Accept, Accounting-Request, Accounting-Response, Status-Server
../data/rfc/rfc6421.txt- and CoA/Disconnect messages.
../data/rfc/rfc6421.txt-
../data/rfc/rfc6421.txt- Since it is expected that the work will occur purely within RADIUS or
../data/rfc/rfc6421.txt- in the transport, message data exchanged with Diameter SHOULD NOT be
../data/rfc/rfc6421.txt- affected.
--
../data/rfc/rfc6421.txt-
../data/rfc/rfc6421.txt- [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
../data/rfc/rfc6421.txt- Key Management", BCP 107, RFC 4107, June 2005.
../data/rfc/rfc6421.txt-
../data/rfc/rfc6421.txt- [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
../data/rfc/rfc6421.txt: Authorization, and Accounting (AAA) Key Management", BCP
../data/rfc/rfc6421.txt- 132, RFC 4962, July 2007.
../data/rfc/rfc6421.txt-
../data/rfc/rfc6421.txt- [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
../data/rfc/rfc6421.txt- for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
../data/rfc/rfc6421.txt- RFC 6151, March 2011.
--
../data/rfc/rfc7713.txt- flow or degrades over time, and what defines the end of the
../data/rfc/rfc7713.txt- duration of a flow;
../data/rfc/rfc7713.txt-
../data/rfc/rfc7713.txt- E. a specification for signal units (bytes vs. packets, etc.),
../data/rfc/rfc7713.txt- any approximations allowed, and the algorithms to do any
../data/rfc/rfc7713.txt: implied conversions or accounting;
../data/rfc/rfc7713.txt-
../data/rfc/rfc7713.txt- F. if the units are bytes, a definition of which headers are
../data/rfc/rfc7713.txt- included in the size of the packet;
../data/rfc/rfc7713.txt-
../data/rfc/rfc7713.txt- G. how tunnels should propagate the ConEx encoding;
--
../data/rfc/rfc2700.txt--------- PPP Bridging Control Protocol (BCP) 2878*
../data/rfc/rfc2700.txt--------- Diffie-Hellman Proof-of-Possession Algorithms 2875*
../data/rfc/rfc2700.txt--------- DNS Extensions to Support IPv6 Address Aggregation 2874*
../data/rfc/rfc2700.txt- and Renumbering
../data/rfc/rfc2700.txt--------- TCP Processing of the IPv4 Precedence Field 2873*
../data/rfc/rfc2700.txt:RADIUS RADIUS Accounting Modifications for Tunnel Protocol 2867*
../data/rfc/rfc2700.txt- Support
../data/rfc/rfc2700.txt--------- The Inverted Stack Table Extension to the Interfaces 2864*
../data/rfc/rfc2700.txt- Group MIB
../data/rfc/rfc2700.txt--------- RTP Payload Format for Real-Time Pointers 2862*
../data/rfc/rfc2700.txt-MEXT-BGP4 Multiprotocol Extensions for BGP-4 2858*
--
../data/rfc/rfc2700.txt-WEBDAV HTTP Extensions for Distributed Authoring -- WEBDAV 2518
../data/rfc/rfc2700.txt-ATM-MIBMAN Definitions of Managed Objects for ATM Management 2515
../data/rfc/rfc2700.txt-ATM-TC-OID Definitions of Textual Conventions and OBJECT- 2514
../data/rfc/rfc2700.txt- IDENTITIES for ATM Management
../data/rfc/rfc2700.txt--------- Managed Objects for Controlling the Collection 2513
../data/rfc/rfc2700.txt: and Storage of Accounting Information for
../data/rfc/rfc2700.txt- Connection-Oriented Networks
../data/rfc/rfc2700.txt:-------- Accounting Information for ATM Networks 2512
../data/rfc/rfc2700.txt-X.509-CRMF Internet X.509 Certificate Request Message Format 2511
../data/rfc/rfc2700.txt-PKICMP Internet X.509 Public Key Infrastructure Certificate 2510
../data/rfc/rfc2700.txt- Management Protocols
../data/rfc/rfc2700.txt-IPCOM-PPP IP Header Compression over PPP 2509
../data/rfc/rfc2700.txt--------- Compressing IP/UDP/RTP Headers for Low-Speed Serial 2508
--
../data/rfc/rfc399.txt-referencing a file. The user name and account number specified
../data/rfc/rfc399.txt-remain in effect until another LGI command is issued, a LGO
../data/rfc/rfc399.txt-command is issued, or the connection is closed.
../data/rfc/rfc399.txt-
../data/rfc/rfc399.txt- At present, the use of SMFS is not billed, and therefore
../data/rfc/rfc399.txt:use of the accounting commands is optional. It is requested,
../data/rfc/rfc399.txt-however, that users and user processes begin to use this command
../data/rfc/rfc399.txt-as soon as possible, since we would like to collect statistics on
../data/rfc/rfc399.txt-SMFS utilization before implementing billing. Therefore, at
../data/rfc/rfc399.txt-present the user name can be any name that identfies the user,
../data/rfc/rfc399.txt-and the account number is completely arbitrary.
--
../data/rfc/rfc399.txt-filenames.
../data/rfc/rfc399.txt-
../data/rfc/rfc399.txt-
../data/rfc/rfc399.txt- Logout (LGO)
../data/rfc/rfc399.txt- The logout command terminates the association between the
../data/rfc/rfc399.txt:user and the accounting information specified in the last LGI
../data/rfc/rfc399.txt-command issued, if any; it does not cause SMFS to close the
../data/rfc/rfc399.txt-connection. The user should then issue another LGI command
../data/rfc/rfc399.txt-before attempting any operation referencing a file. It is not
../data/rfc/rfc399.txt-necessary to issue a LGO command before issuing another LGI
../data/rfc/rfc399.txt-command, or before closing the connection.
--
../data/rfc/rfc5320.txt- 3. Applicability Statement .........................................7
../data/rfc/rfc5320.txt- 4. SEAL Protocol Specification - Tunnel Mode .......................8
../data/rfc/rfc5320.txt- 4.1. Model of Operation .........................................8
../data/rfc/rfc5320.txt- 4.2. ITE Specification .........................................10
../data/rfc/rfc5320.txt- 4.2.1. Tunnel Interface MTU ...............................10
../data/rfc/rfc5320.txt: 4.2.2. Accounting for Headers .............................11
../data/rfc/rfc5320.txt- 4.2.3. Segmentation and Encapsulation .....................12
../data/rfc/rfc5320.txt- 4.2.4. Sending Probes .....................................14
../data/rfc/rfc5320.txt- 4.2.5. Packet Identification ..............................15
../data/rfc/rfc5320.txt- 4.2.6. Sending SEAL Protocol Packets ......................15
../data/rfc/rfc5320.txt- 4.2.7. Processing Raw ICMPv4 Messages .....................15
--
../data/rfc/rfc5320.txt- independent packet. For all other inner packets (IPv4 or IPv6), the
../data/rfc/rfc5320.txt- ITE admits the packet if it is no larger than the tunnel interface
../data/rfc/rfc5320.txt- MTU; otherwise, it drops the packet and sends an ICMP PTB message
../data/rfc/rfc5320.txt- with an MTU value of the tunnel interface MTU to the source.
../data/rfc/rfc5320.txt-
../data/rfc/rfc5320.txt:4.2.2. Accounting for Headers
../data/rfc/rfc5320.txt-
../data/rfc/rfc5320.txt- As for any transport layer protocol, ITEs use the MTU of the
../data/rfc/rfc5320.txt- underlying IPv4 interface, the length of any mid-layer '*' headers
../data/rfc/rfc5320.txt- and trailers, and the length of the outer SEAL/*/IPv4 headers to
../data/rfc/rfc5320.txt- determine the maximum size for a SEAL segment (see Section 4.2.3).
--
../data/rfc/rfc3752.txt- them. Examples include:
../data/rfc/rfc3752.txt-
../data/rfc/rfc3752.txt- o Logging/Monitoring: Each response may be examined and recorded for
../data/rfc/rfc3752.txt- monitoring or debugging purposes.
../data/rfc/rfc3752.txt-
../data/rfc/rfc3752.txt: o Accounting: An OPES processor may record the usage data (time and
../data/rfc/rfc3752.txt- space) of each service request for billing purposes.
../data/rfc/rfc3752.txt-
../data/rfc/rfc3752.txt-2.3. Services creating responses
../data/rfc/rfc3752.txt-
../data/rfc/rfc3752.txt- Services creating responses may include OPES services that
--
../data/rfc/rfc4949.txt- subsequent investigation of security breaches. Individual persons
../data/rfc/rfc4949.txt- who are system users are held accountable for their actions after
../data/rfc/rfc4949.txt- being notified of the rules of behavior for using the system and
../data/rfc/rfc4949.txt- the penalties associated with violating those rules.
../data/rfc/rfc4949.txt-
../data/rfc/rfc4949.txt: $ accounting See: COMSEC accounting.
../data/rfc/rfc4949.txt-
../data/rfc/rfc4949.txt: $ accounting legend code (ALC)
../data/rfc/rfc4949.txt- (O) /U.S. Government/ Numeric system used to indicate the minimum
../data/rfc/rfc4949.txt: accounting controls required for items of COMSEC material within
../data/rfc/rfc4949.txt: the CMCS. [C4009] (See: COMSEC accounting.)
../data/rfc/rfc4949.txt-
../data/rfc/rfc4949.txt- $ accreditation
../data/rfc/rfc4949.txt- (N) An administrative action by which a designated authority
../data/rfc/rfc4949.txt- declares that an information system is approved to operate in a
../data/rfc/rfc4949.txt- particular security configuration with a prescribed set of
--
../data/rfc/rfc4949.txt- room. If A and B operate in different security domains, then
../data/rfc/rfc4949.txt- moving data across the air gap may involve an upgrade or downgrade
../data/rfc/rfc4949.txt- operation.
../data/rfc/rfc4949.txt-
../data/rfc/rfc4949.txt- $ ALC
../data/rfc/rfc4949.txt: (O) See: accounting legend code.
../data/rfc/rfc4949.txt-
../data/rfc/rfc4949.txt-
../data/rfc/rfc4949.txt-
../data/rfc/rfc4949.txt-
../data/rfc/rfc4949.txt-
--
../data/rfc/rfc4949.txt-
../data/rfc/rfc4949.txt-
../data/rfc/rfc4949.txt- Information Security Foundation chartered by the U.S. Government)
../data/rfc/rfc4949.txt- have not been implemented at all, and others (e.g., codifying
../data/rfc/rfc4949.txt- Generally Accepted System Security Principles similar to
../data/rfc/rfc4949.txt: accounting principles) have been implemented but not widely
../data/rfc/rfc4949.txt- adopted [SP14, SP27].
../data/rfc/rfc4949.txt-
../data/rfc/rfc4949.txt- $ COMSEC
../data/rfc/rfc4949.txt- (I) See: communication security.
../data/rfc/rfc4949.txt-
../data/rfc/rfc4949.txt- $ COMSEC account
../data/rfc/rfc4949.txt- (O) /U.S. Government/ "Administrative entity, identified by an
../data/rfc/rfc4949.txt- account number, used to maintain accountability, custody, and
../data/rfc/rfc4949.txt- control of COMSEC material." [C4009] (See: COMSEC custodian.)
../data/rfc/rfc4949.txt-
../data/rfc/rfc4949.txt: $ COMSEC accounting
../data/rfc/rfc4949.txt- (O) /U.S. Government/ The process of creating, collecting, and
../data/rfc/rfc4949.txt- maintaining data records that describe the status and custody of
../data/rfc/rfc4949.txt: designated items of COMSEC material. (See: accounting legend
../data/rfc/rfc4949.txt- code.)
../data/rfc/rfc4949.txt-
../data/rfc/rfc4949.txt- Tutorial: Almost any secure information system needs to record a
../data/rfc/rfc4949.txt- security audit trail, but a system that manages COMSEC material
../data/rfc/rfc4949.txt- needs to record additional data about the status and custody of
--
../data/rfc/rfc4949.txt- key generation and key handling and storage." [C4009] (Compare:
../data/rfc/rfc4949.txt- cryptographic boundary.)
../data/rfc/rfc4949.txt-
../data/rfc/rfc4949.txt- $ COMSEC custodian
../data/rfc/rfc4949.txt- (O) /U.S. Government/ "Individual designated by proper authority
../data/rfc/rfc4949.txt: to be responsible for the receipt, transfer, accounting,
../data/rfc/rfc4949.txt- safeguarding, and destruction of COMSEC material assigned to a
../data/rfc/rfc4949.txt- COMSEC account." [C4009]
../data/rfc/rfc4949.txt-
../data/rfc/rfc4949.txt- $ COMSEC material
../data/rfc/rfc4949.txt- (N) /U.S. Government/ Items designed to secure or authenticate
--
../data/rfc/rfc4949.txt- and software that embodies or describes cryptographic logic; and
../data/rfc/rfc4949.txt- other items that perform COMSEC functions. [C4009] (Compare:
../data/rfc/rfc4949.txt- keying material.)
../data/rfc/rfc4949.txt-
../data/rfc/rfc4949.txt- $ COMSEC Material Control System (CMCS)
../data/rfc/rfc4949.txt: (O) /U.S. Government/ "Logistics and accounting system through
../data/rfc/rfc4949.txt- which COMSEC material marked 'CRYPTO' is distributed, controlled,
../data/rfc/rfc4949.txt- and safeguarded." [C4009] (See: COMSEC account, COMSEC custodian.)
../data/rfc/rfc4949.txt-
../data/rfc/rfc4949.txt- $ confidentiality
../data/rfc/rfc4949.txt- See: data confidentiality.
--
../data/rfc/rfc4949.txt- of that process. (See: key distribution, key escrow, keying
../data/rfc/rfc4949.txt- material, public-key infrastructure.)
../data/rfc/rfc4949.txt-
../data/rfc/rfc4949.txt- Usage: Usually understood to include ordering, generating,
../data/rfc/rfc4949.txt- storing, archiving, escrowing, distributing, loading, destroying,
../data/rfc/rfc4949.txt: auditing, and accounting for the material.
../data/rfc/rfc4949.txt-
../data/rfc/rfc4949.txt- 1b. (O) /NIST/ "The activities involving the handling of
../data/rfc/rfc4949.txt- cryptographic keys and other related security parameters (e.g.,
../data/rfc/rfc4949.txt-
../data/rfc/rfc4949.txt-
--
../data/rfc/rfc4949.txt- (I) An independent review and examination of a system's records
../data/rfc/rfc4949.txt- and activities to determine the adequacy of system controls,
../data/rfc/rfc4949.txt- ensure compliance with established security policy and procedures,
../data/rfc/rfc4949.txt- detect breaches in security services, and recommend any changes
../data/rfc/rfc4949.txt- that are indicated for countermeasures. [I7498-2, NCS01] (Compare:
../data/rfc/rfc4949.txt: accounting, intrusion detection.)
../data/rfc/rfc4949.txt-
../data/rfc/rfc4949.txt- Tutorial: The basic audit objective is to establish accountability
../data/rfc/rfc4949.txt- for system entities that initiate or participate in security-
../data/rfc/rfc4949.txt- relevant events and actions. Thus, means are needed to generate
../data/rfc/rfc4949.txt- and record a security audit trail and to review and analyze the
--
../data/rfc/rfc4949.txt- emanation. Compare: SCIF.)
../data/rfc/rfc4949.txt-
../data/rfc/rfc4949.txt- $ short title
../data/rfc/rfc4949.txt- (O) "Identifying combination of letters and numbers assigned to
../data/rfc/rfc4949.txt- certain items of COMSEC material to facilitate handling,
../data/rfc/rfc4949.txt: accounting, and controlling." [C4009] (Compare: KMID, long title.)
../data/rfc/rfc4949.txt-
../data/rfc/rfc4949.txt-
../data/rfc/rfc4949.txt-
../data/rfc/rfc4949.txt-Shirey Informational [Page 281]
../data/rfc/rfc4949.txt-
--
../data/rfc/rfc4949.txt- $ TACACS
../data/rfc/rfc4949.txt- (I) See: Terminal Access Controller (TAC) Access Control System.
../data/rfc/rfc4949.txt-
../data/rfc/rfc4949.txt- $ TACACS+
../data/rfc/rfc4949.txt- (I) A TCP-based protocol that improves on TACACS by separating the
../data/rfc/rfc4949.txt: functions of authentication, authorization, and accounting and by
../data/rfc/rfc4949.txt- encrypting all traffic between the network access server and
../data/rfc/rfc4949.txt-
../data/rfc/rfc4949.txt-
../data/rfc/rfc4949.txt-
../data/rfc/rfc4949.txt-Shirey Informational [Page 300]
--
../data/rfc/rfc3871.txt-RFC 3871 Operational Security Requirements September 2004
../data/rfc/rfc3871.txt-
../data/rfc/rfc3871.txt-
../data/rfc/rfc3871.txt- 2.11.10. Logs Contain Records Of Security Events . . . . 54
../data/rfc/rfc3871.txt- 2.11.11. Logs Do Not Contain Passwords . . . . . . . . . 55
../data/rfc/rfc3871.txt: 2.12. Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc3871.txt- Requirements . . . . . . . . . . . . . . . . . . . . . . 55
../data/rfc/rfc3871.txt- 2.12.1. Authenticate All User Access. . . . . . . . . . 55
../data/rfc/rfc3871.txt- 2.12.2. Support Authentication of Individual Users. . . 56
../data/rfc/rfc3871.txt- 2.12.3. Support Simultaneous Connections. . . . . . . . 56
../data/rfc/rfc3871.txt- 2.12.4. Ability to Disable All Local Accounts . . . . . 57
--
../data/rfc/rfc3871.txt-
../data/rfc/rfc3871.txt- This information is necessary to enable a thorough assessment of
../data/rfc/rfc3871.txt- the security risks associated with the operation of the device
../data/rfc/rfc3871.txt- (e.g., "does this protocol allow complete management of the device
../data/rfc/rfc3871.txt- without also requiring authentication, authorization, or
../data/rfc/rfc3871.txt: accounting?"). The information also assists in determining what
../data/rfc/rfc3871.txt- steps should be taken to mitigate risk (e.g., "should I turn this
../data/rfc/rfc3871.txt- service off ?")
../data/rfc/rfc3871.txt-
../data/rfc/rfc3871.txt-
../data/rfc/rfc3871.txt-
--
../data/rfc/rfc3871.txt- records of successful or failed authentication attempts.
../data/rfc/rfc3871.txt-
../data/rfc/rfc3871.txt- Justification.
../data/rfc/rfc3871.txt-
../data/rfc/rfc3871.txt- Access control and authorization requirements differ for
../data/rfc/rfc3871.txt: accounting records (logs) and authorization databases (passwords).
../data/rfc/rfc3871.txt- Logging passwords may grant unauthorized access to individuals
../data/rfc/rfc3871.txt- with access to the logs. Logging failed passwords may give hints
../data/rfc/rfc3871.txt- about actual passwords. See section 4.5.4.4 of [RFC2196].
../data/rfc/rfc3871.txt-
../data/rfc/rfc3871.txt- Examples.
--
../data/rfc/rfc3871.txt- Warnings.
../data/rfc/rfc3871.txt-
../data/rfc/rfc3871.txt- There may be situations where it is appropriate/required to log
../data/rfc/rfc3871.txt- passwords.
../data/rfc/rfc3871.txt-
../data/rfc/rfc3871.txt:2.12. Authentication, Authorization, and Accounting (AAA) Requirements
../data/rfc/rfc3871.txt-
../data/rfc/rfc3871.txt-2.12.1. Authenticate All User Access
../data/rfc/rfc3871.txt-
../data/rfc/rfc3871.txt- Requirement.
../data/rfc/rfc3871.txt-
--
../data/rfc/rfc1380.txt-
../data/rfc/rfc1380.txt-RFC 1380 ROAD November 1992
../data/rfc/rfc1380.txt-
../data/rfc/rfc1380.txt-
../data/rfc/rfc1380.txt- emerging internet problems such as security/authentication, mobility,
../data/rfc/rfc1380.txt: resource allocation, accounting, high packet rates, etc.
../data/rfc/rfc1380.txt-
../data/rfc/rfc1380.txt-Appendix C. BIBLIOGRAPHY
../data/rfc/rfc1380.txt-
../data/rfc/rfc1380.txt--Documents and Information from IETF/IESG:
../data/rfc/rfc1380.txt-
--
../data/rfc/rfc3954.txt-
../data/rfc/rfc3954.txt- Cisco Systems' NetFlow services provide network administrators with
../data/rfc/rfc3954.txt- access to IP flow information from their data networks. Network
../data/rfc/rfc3954.txt- elements (routers and switches) gather flow data and export it to
../data/rfc/rfc3954.txt- collectors. The collected data provides fine-grained metering for
../data/rfc/rfc3954.txt: highly flexible and detailed resource usage accounting.
../data/rfc/rfc3954.txt-
../data/rfc/rfc3954.txt- A flow is defined as a unidirectional sequence of packets with some
../data/rfc/rfc3954.txt- common properties that pass through a network device. These
../data/rfc/rfc3954.txt- collected flows are exported to an external device, the NetFlow
../data/rfc/rfc3954.txt- collector. Network flows are highly granular; for example, flow
../data/rfc/rfc3954.txt- records include details such as IP addresses, packet and byte counts,
../data/rfc/rfc3954.txt- timestamps, Type of Service (ToS), application ports, input and
../data/rfc/rfc3954.txt- output interfaces, etc.
../data/rfc/rfc3954.txt-
../data/rfc/rfc3954.txt- Exported NetFlow data is used for a variety of purposes, including
../data/rfc/rfc3954.txt: enterprise accounting and departmental chargebacks, ISP billing, data
../data/rfc/rfc3954.txt-
../data/rfc/rfc3954.txt-
../data/rfc/rfc3954.txt-
../data/rfc/rfc3954.txt-Claise Informational [Page 2]
../data/rfc/rfc3954.txt-
--
../data/rfc/rfc3954.txt- activities, whilst a Flow Record only containing the source and
../data/rfc/rfc3954.txt- destination IP network would be less revealing.
../data/rfc/rfc3954.txt-
../data/rfc/rfc3954.txt-10.2. Forgery of Flow Records or Template Records
../data/rfc/rfc3954.txt-
../data/rfc/rfc3954.txt: If Flow Records are used in accounting and/or security applications,
../data/rfc/rfc3954.txt- there may be a strong incentive to forge exported Flow Records (for
../data/rfc/rfc3954.txt- example to defraud the service provider, or to prevent the detection
../data/rfc/rfc3954.txt- of an attack). This can be done either by altering the Flow Records
../data/rfc/rfc3954.txt- on the path between the Observer and the Collector, or by injecting
../data/rfc/rfc3954.txt- forged Flow Records that pretend to be originated by the Exporter.
--
../data/rfc/rfc3053.txt-
../data/rfc/rfc3053.txt- The client of the Tunnel Broker service is a dual-stack IPv6 node
../data/rfc/rfc3053.txt- (host or router) connected to the IPv4 Internet. Approaching the TB,
../data/rfc/rfc3053.txt- the client should be asked first of all to provide its identity and
../data/rfc/rfc3053.txt- credentials so that proper user authentication, authorization and
../data/rfc/rfc3053.txt: (optionally) accounting can be carried out (e.g., relying on existing
../data/rfc/rfc3053.txt- AAA facilities such as RADIUS). This means that the client and the
../data/rfc/rfc3053.txt- TB have to share a pre-configured or automatically established
../data/rfc/rfc3053.txt- security association to be used to prevent unauthorized use of the
../data/rfc/rfc3053.txt- service. With this respect the TB can be seen as an access-control
../data/rfc/rfc3053.txt- server for IPv4 interconnected IPv6 users.
--
../data/rfc/rfc3053.txt- (e.g. broker.isp-name.com).
../data/rfc/rfc3053.txt-
../data/rfc/rfc3053.txt-2.7 Open issues
../data/rfc/rfc3053.txt-
../data/rfc/rfc3053.txt- Real usage of the TB service may require the introduction of
../data/rfc/rfc3053.txt: accounting/billing functions.
../data/rfc/rfc3053.txt-
../data/rfc/rfc3053.txt-3. Known limitations
../data/rfc/rfc3053.txt-
../data/rfc/rfc3053.txt- This mechanism may not work if the user is using private IPv4
../data/rfc/rfc3053.txt- addresses behind a NAT box.
--
../data/rfc/rfc4120.txt- Encryption for Authentication in Large Networks of
../data/rfc/rfc4120.txt- Computers," Communications of the ACM, Vol. 21
../data/rfc/rfc4120.txt- (12), pp. 993-999, December 1978.
../data/rfc/rfc4120.txt-
../data/rfc/rfc4120.txt- [Neu93] B. Clifford Neuman, "Proxy-Based Authorization and
../data/rfc/rfc4120.txt: Accounting for Distributed Systems," in
../data/rfc/rfc4120.txt- Proceedings of the 13th International Conference
../data/rfc/rfc4120.txt- on Distributed Computing Systems, Pittsburgh, PA,
../data/rfc/rfc4120.txt- May 1993.
../data/rfc/rfc4120.txt-
../data/rfc/rfc4120.txt-
--
../data/rfc/rfc615.txt-I believe that any modifications to the syntax will be graceful
../data/rfc/rfc615.txt-additions, rather than wholesale redesign, and thus can be deferred for a
../data/rfc/rfc615.txt-while. Currently, any undefined attributes must be specified in a
../data/rfc/rfc615.txt-Siteparm field:
../data/rfc/rfc615.txt-
../data/rfc/rfc615.txt:Perhaps Version, Access protection and Accounting, as well as other types
../data/rfc/rfc615.txt-of information, should be made standard <key>s, rather than buried as
../data/rfc/rfc615.txt-Siteparms. I expect that the next version of the NSDP Syntax
../data/rfc/rfc615.txt-specification will include them as <key>s, but I would like to wait for
../data/rfc/rfc615.txt-some comments from the community.
../data/rfc/rfc615.txt-
--
../data/rfc/rfc2680.txt-
../data/rfc/rfc2680.txt-
../data/rfc/rfc2680.txt-2.7. Errors and Uncertainties:
../data/rfc/rfc2680.txt-
../data/rfc/rfc2680.txt- The description of any specific measurement method should include an
../data/rfc/rfc2680.txt: accounting and analysis of various sources of error or uncertainty.
../data/rfc/rfc2680.txt- The Framework document provides general guidance on this point.
../data/rfc/rfc2680.txt-
../data/rfc/rfc2680.txt- For loss, there are three sources of error:
../data/rfc/rfc2680.txt-
../data/rfc/rfc2680.txt- + Synchronization between clocks on Src and Dst.
--
../data/rfc/rfc4139.txt-
../data/rfc/rfc4139.txt- Management Plane: Performs management functions for the Transport
../data/rfc/rfc4139.txt- Plane, the control plane, and the system as a whole. It also
../data/rfc/rfc4139.txt- provides coordination between all the planes. The following
../data/rfc/rfc4139.txt- management functional areas are performed in the management plane:
../data/rfc/rfc4139.txt: performance, fault, configuration, accounting, and security
../data/rfc/rfc4139.txt- management.
../data/rfc/rfc4139.txt-
../data/rfc/rfc4139.txt- Management Domain: See Recommendation G.805 [ITU-T-G.805].
../data/rfc/rfc4139.txt-
../data/rfc/rfc4139.txt- Transport Plane: Provides bi-directional or unidirectional transfer
--
../data/rfc/rfc1346.txt-Network Working Group P. Jones
../data/rfc/rfc1346.txt-Request for Comments: 1346 Joint Network Team, UK
../data/rfc/rfc1346.txt- June 1992
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt: Resource Allocation, Control, and Accounting
../data/rfc/rfc1346.txt- for the Use of Network Resources
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt-Status of this Memo
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt- This memo provides information for the Internet community. It does
--
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt-Jones [Page 1]
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt:RFC 1346 Resource Allocation, Control, and Accounting June 1992
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt- Often the situation can appear worse than having to survive in a
../data/rfc/rfc1346.txt- jungle, in the sense that the strong (even if "good") seem to have
../data/rfc/rfc1346.txt- little advantage over the weak. It may seem that it is the
--
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt-Jones [Page 2]
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt:RFC 1346 Resource Allocation, Control, and Accounting June 1992
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt- (d) It may be Network Manager A has a link that Network Manager B
../data/rfc/rfc1346.txt- would like to use on occasion, perhaps as back-up on access to a
../data/rfc/rfc1346.txt- third network. Network Manager A might well wish to be
--
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt-Jones [Page 3]
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt:RFC 1346 Resource Allocation, Control, and Accounting June 1992
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt- Time is an important factor. Network resources, like computer
../data/rfc/rfc1346.txt- processor time and unlike filestore, vanish if they are not used.
../data/rfc/rfc1346.txt- People will in general prefer resources during prime shift to those
--
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt-Jones [Page 4]
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt:RFC 1346 Resource Allocation, Control, and Accounting June 1992
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt- the choices are if any), is not clear.
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt- 2.3 Following from that, it is then not clear whether what is
--
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt-Jones [Page 5]
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt:RFC 1346 Resource Allocation, Control, and Accounting June 1992
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt-Security Considerations
../data/rfc/rfc1346.txt-
../data/rfc/rfc1346.txt- Security issues are not discussed in this memo.
--
../data/rfc/rfc2477.txt-Aboba & Zorn Informational [Page 2]
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt-RFC 2477 Evaluating Roaming Protocols January 1999
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt: Accounting server
../data/rfc/rfc2477.txt: This is a server which provides for accounting within the roaming
../data/rfc/rfc2477.txt- architecture.
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt- Authentication proxy
../data/rfc/rfc2477.txt- Authentication proxies may be deployed within the roaming
../data/rfc/rfc2477.txt- architecture for several purposes, including authentication
../data/rfc/rfc2477.txt- forwarding, policy implementation, shared secret management, and
../data/rfc/rfc2477.txt- attribute editing. To the NAS, the authentication proxy appears
../data/rfc/rfc2477.txt- to act as an authentication server; to the authentication server,
../data/rfc/rfc2477.txt- the proxy appears to act as an authentication client.
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt: Accounting proxy
../data/rfc/rfc2477.txt: Accounting proxies may be deployed within the roaming architecture
../data/rfc/rfc2477.txt: for several purposes, including accounting forwarding, reliability
../data/rfc/rfc2477.txt- improvement, auditing, and "pseudo-transactional" capability. To
../data/rfc/rfc2477.txt: the NAS, the accounting proxy appears to act as an accounting
../data/rfc/rfc2477.txt: server; to the accounting server, the proxy appears to act as an
../data/rfc/rfc2477.txt: accounting client.
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt- Network Access Identifier
../data/rfc/rfc2477.txt- In order to provide for the routing of authentication and
../data/rfc/rfc2477.txt: accounting packets, user name MAY contain structure. This
../data/rfc/rfc2477.txt- structure provides a means by which the authentication or
../data/rfc/rfc2477.txt: accounting proxies will locate the authentication or accounting
../data/rfc/rfc2477.txt- server that is to receive the request.
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt-3. Architectural framework
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt- The roaming architecture consists of three major subsystems:
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt- Phone book Subsystem
../data/rfc/rfc2477.txt- Authentication Subsystem
../data/rfc/rfc2477.txt: Accounting Subsystem
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt- The phone book subsystem is concerned with the maintenance and
../data/rfc/rfc2477.txt- updating of the user phone book. The phone book provides the user
../data/rfc/rfc2477.txt- with information on the location and phone numbers of Points of
../data/rfc/rfc2477.txt- Presence (POPs) that are roaming enabled. The function of the
../data/rfc/rfc2477.txt- authentication subsystem is to provide authorized users with access
../data/rfc/rfc2477.txt- to the POPs in the phonebook, and to deny access to unauthorized
../data/rfc/rfc2477.txt: users. The goal of the accounting subsystem is to provide
../data/rfc/rfc2477.txt- information on the resources utilized during the user's session.
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt-3.1. Phone Book Subsystem
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt- The phone book subsystem provides for the following:
--
../data/rfc/rfc2477.txt- Security
../data/rfc/rfc2477.txt- In the process of authenticating and authorizing the user session,
../data/rfc/rfc2477.txt- it may be desirable to provide protection against a variety of
../data/rfc/rfc2477.txt- security threats.
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt:3.3. Accounting Subsystem
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt: The function of the accounting subsystem is to enable the
../data/rfc/rfc2477.txt- participants in the roaming consortium to keep track of what
../data/rfc/rfc2477.txt- resources are used during a session. Relevant information includes
../data/rfc/rfc2477.txt- how long the user was connected to the service, connection speed,
../data/rfc/rfc2477.txt- port type, etc.
../data/rfc/rfc2477.txt-
--
../data/rfc/rfc2477.txt- provide sufficient scalability to allow for the formation of
../data/rfc/rfc2477.txt- roaming associations with thousands of ISP members.
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt- RADIUS Support
../data/rfc/rfc2477.txt- Given the current popularity and near ubiquity of RADIUS [2,3] as
../data/rfc/rfc2477.txt: an authentication, authorization and accounting solution, a
../data/rfc/rfc2477.txt- roaming standard MUST be able to incorporate RADIUS-enabled
../data/rfc/rfc2477.txt- devices within the roaming architecture. It is expected that this
../data/rfc/rfc2477.txt- will be accomplished by development of gateways between RADIUS and
../data/rfc/rfc2477.txt: the roaming standard authentication, authorization, and accounting
../data/rfc/rfc2477.txt- protocol.
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt-4.2.4. NAS Configuration/Authorization
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt- In order to ensure compatibility with the NAS or the local network,
--
../data/rfc/rfc2477.txt- to support data object security. As a result, a roaming standard
../data/rfc/rfc2477.txt- MUST provide end-to-end confidentiality and integrity protection
../data/rfc/rfc2477.txt- on an attribute-by-attribute basis. However, non-repudiation is
../data/rfc/rfc2477.txt- NOT a requirement for a roaming standard.
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt:4.3. Accounting requirements
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt: Real-time accounting
../data/rfc/rfc2477.txt: In today's roaming implementations, real-time accounting is a
../data/rfc/rfc2477.txt- practical necessity in order to support fraud detection and risk
../data/rfc/rfc2477.txt- management. As a result, a roaming standard MUST provide support
../data/rfc/rfc2477.txt: for real-time accounting.
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt: Accounting record formats
../data/rfc/rfc2477.txt: Today there is no proposed standard for NAS accounting, and there
../data/rfc/rfc2477.txt- is wide variation in the protocols used by providers to
../data/rfc/rfc2477.txt: communicate accounting information within their own organizations.
../data/rfc/rfc2477.txt- Therefore, a roaming standard MUST prescribe a standardized format
../data/rfc/rfc2477.txt: for accounting records. For the sake of efficiency, the record
../data/rfc/rfc2477.txt- format MUST be compact.
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt- Extensibility
../data/rfc/rfc2477.txt: A standard accounting record format MUST be able to encode metrics
../data/rfc/rfc2477.txt- commonly used to determine the user's bill. Since these metrics
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt-Aboba & Zorn Informational [Page 9]
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt-RFC 2477 Evaluating Roaming Protocols January 1999
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt: change over time, the accounting record format MUST be extensible
../data/rfc/rfc2477.txt- so as to be able to add future metrics as they come along. The
../data/rfc/rfc2477.txt- record format MUST support both standard metrics as well as
../data/rfc/rfc2477.txt- vendor-specific metrics.
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt-5. References
--
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt- [2] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
../data/rfc/rfc2477.txt- Authentication Dial In User Service (RADIUS)", RFC 2138, April
../data/rfc/rfc2477.txt- 1997.
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt: [3] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt- [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
../data/rfc/rfc2477.txt- Levels", BCP 14, RFC 2119, March 1997.
../data/rfc/rfc2477.txt-
../data/rfc/rfc2477.txt- [5] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
--
../data/rfc/rfc3010.txt- With delegations, a client is able to avoid writing data to the
../data/rfc/rfc3010.txt- server when the CLOSE of a file is serviced. The CLOSE operation is
../data/rfc/rfc3010.txt- the usual point at which the client is notified of a lack of stable
../data/rfc/rfc3010.txt- storage for the modified file data generated by the application. At
../data/rfc/rfc3010.txt- the CLOSE, file data is written to the server and through normal
../data/rfc/rfc3010.txt: accounting the server is able to determine if the available file
../data/rfc/rfc3010.txt- system space for the data has been exceeded (i.e. server returns
../data/rfc/rfc3010.txt: NFS4ERR_NOSPC or NFS4ERR_DQUOT). This accounting includes quotas.
../data/rfc/rfc3010.txt- The introduction of delegations requires that a alternative method be
../data/rfc/rfc3010.txt- in place for the same type of communication to occur between client
../data/rfc/rfc3010.txt- and server.
../data/rfc/rfc3010.txt-
../data/rfc/rfc3010.txt- In the delegation response, the server provides either the limit of
--
../data/rfc/rfc1192.txt- area network services -- and possibly avoid the imposition of
../data/rfc/rfc1192.txt- standard institutional overhead on direct funding. However, if
../data/rfc/rfc1192.txt- vouchers can be sold to other institutions, as economists would
../data/rfc/rfc1192.txt- advocate in the interests of market efficiency, these advantages may
../data/rfc/rfc1192.txt- be compromised. Even non-transferable vouchers may create a unique
../data/rfc/rfc1192.txt: set of accounting problems for both funding agencies and
../data/rfc/rfc1192.txt- institutional recipients.
../data/rfc/rfc1192.txt-
../data/rfc/rfc1192.txt- A federal subsidy channeled automatically to research grants could
../data/rfc/rfc1192.txt- substantially limit or segregate the user community. It would tend
../data/rfc/rfc1192.txt- to divide the academic community by exacerbating obvious divisions
--
../data/rfc/rfc1192.txt- TymNet), which are sometimes seen as competitive to Internet
../data/rfc/rfc1192.txt- services, do bill on a connect-time basis. However, these commercial
../data/rfc/rfc1192.txt- services use X.25 connection-based packet-switching -- rather than
../data/rfc/rfc1192.txt- the connectionless (datagram) TCP/IP packet-switching used on the
../data/rfc/rfc1192.txt- Internet. Internet services could conceivably be billed on per-
../data/rfc/rfc1192.txt: packet basis, but the accounting overhead would be high and packets
../data/rfc/rfc1192.txt- do not contain information about individual users. At bottom, this
../data/rfc/rfc1192.txt- is a marketing issue, and there is no evidence of any market for
../data/rfc/rfc1192.txt- metered services -- except possibly among very small users. The
../data/rfc/rfc1192.txt- private suppliers, Alternet and PSI, both sell "pipes" not packets.
../data/rfc/rfc1192.txt-
--
../data/rfc/rfc1700.txt-64-149 Unassigned [JBP]
../data/rfc/rfc1700.txt-150 Xerox NS IDP [ETHERNET,XEROX]
../data/rfc/rfc1700.txt-151 Unassigned [JBP]
../data/rfc/rfc1700.txt-152 PARC Universal Protocol [PUP,XEROX]
../data/rfc/rfc1700.txt-153 TIP Status Reporting [JGH]
../data/rfc/rfc1700.txt:154 TIP Accounting [JGH]
../data/rfc/rfc1700.txt-155 Internet Protocol [regular] [RFC791,JBP]
../data/rfc/rfc1700.txt-156-158 Internet Protocol [experimental] [RFC791,JBP]
../data/rfc/rfc1700.txt-159 Figleaf Link [JBW1]
../data/rfc/rfc1700.txt-160 Blacker Local Network Protocol [DM28]
../data/rfc/rfc1700.txt-161-194 Unassigned [JBP]
--
../data/rfc/rfc7597.txt- part of obtaining IPv6 Internet access.
../data/rfc/rfc7597.txt-
../data/rfc/rfc7597.txt- The MAP provisioning parameters, and hence the IPv4 service itself,
../data/rfc/rfc7597.txt- are tied to the associated End-user IPv6 prefix lifetime; thus, the
../data/rfc/rfc7597.txt- MAP service is also tied to this in terms of authorization,
../data/rfc/rfc7597.txt: accounting, etc.
../data/rfc/rfc7597.txt-
../data/rfc/rfc7597.txt- A single MAP CE MAY be connected to more than one MAP domain, just as
../data/rfc/rfc7597.txt- any router may have more than one IPv4-enabled service-provider-
../data/rfc/rfc7597.txt- facing interface and more than one set of associated addresses
../data/rfc/rfc7597.txt- assigned by DHCP. Each domain within which a given CE operates would
--
../data/rfc/rfc7406.txt-
../data/rfc/rfc7406.txt- In the context of NAA, the IAP and the ISP will probably want to make
../data/rfc/rfc7406.txt- sure that the claimed emergency caller indeed performs an emergency
../data/rfc/rfc7406.txt- call rather than using the network for other purposes, and thereby
../data/rfc/rfc7406.txt- acting fraudulent by skipping any authentication, authorization, and
../data/rfc/rfc7406.txt: accounting procedures. By restricting access of the unauthenticated
../data/rfc/rfc7406.txt- emergency caller to the LoST server and the PSAP URI, traffic can be
../data/rfc/rfc7406.txt- restricted only to emergency calls. This can be accomplished with
../data/rfc/rfc7406.txt- traffic separation. However, the details, e.g., for using filtering,
../data/rfc/rfc7406.txt-
../data/rfc/rfc7406.txt-
--
../data/rfc/rfc3318.txt-
../data/rfc/rfc3318.txt-RFC 3318 Framework Policy Information Base March 2003
../data/rfc/rfc3318.txt-
../data/rfc/rfc3318.txt-
../data/rfc/rfc3318.txt- implementation specific and may be used for other policy related
../data/rfc/rfc3318.txt: functions like flow accounting purposes and/or other data path
../data/rfc/rfc3318.txt- treatments.
../data/rfc/rfc3318.txt-
../data/rfc/rfc3318.txt-5. The Framework PIB Module
../data/rfc/rfc3318.txt-
../data/rfc/rfc3318.txt- FRAMEWORK-PIB PIB-DEFINITIONS ::= BEGIN
--
../data/rfc/rfc3318.txt- SYNTAX OCTET STRING
../data/rfc/rfc3318.txt- STATUS current
../data/rfc/rfc3318.txt- DESCRIPTION
../data/rfc/rfc3318.txt- "This internal label is implementation specific and may be
../data/rfc/rfc3318.txt- used for other policy related functions like flow
../data/rfc/rfc3318.txt: accounting purposes and/or other data path treatments."
../data/rfc/rfc3318.txt-
../data/rfc/rfc3318.txt- ::= { frwkILabelMarkerEntry 2 }
../data/rfc/rfc3318.txt-
../data/rfc/rfc3318.txt-
../data/rfc/rfc3318.txt-
--
../data/rfc/rfc959.txt- the control connections are made (some servers may require
../data/rfc/rfc959.txt- this). Additional identification information in the form of
../data/rfc/rfc959.txt- a password and/or an account command may also be required by
../data/rfc/rfc959.txt- some servers. Servers may allow a new USER command to be
../data/rfc/rfc959.txt- entered at any point in order to change the access control
../data/rfc/rfc959.txt: and/or accounting information. This has the effect of
../data/rfc/rfc959.txt- flushing any user, password, and account information already
../data/rfc/rfc959.txt- supplied and beginning the login sequence again. All
../data/rfc/rfc959.txt- transfer parameters are unchanged and any file transfer in
../data/rfc/rfc959.txt- progress is completed under the old access control
../data/rfc/rfc959.txt- parameters.
--
../data/rfc/rfc959.txt-
../data/rfc/rfc959.txt- CHANGE WORKING DIRECTORY (CWD)
../data/rfc/rfc959.txt-
../data/rfc/rfc959.txt- This command allows the user to work with a different
../data/rfc/rfc959.txt- directory or dataset for file storage or retrieval without
../data/rfc/rfc959.txt: altering his login or accounting information. Transfer
../data/rfc/rfc959.txt- parameters are similarly unchanged. The argument is a
../data/rfc/rfc959.txt- pathname specifying a directory or other system dependent
../data/rfc/rfc959.txt- file group designator.
../data/rfc/rfc959.txt-
../data/rfc/rfc959.txt- CHANGE TO PARENT DIRECTORY (CDUP)
--
../data/rfc/rfc959.txt-
../data/rfc/rfc959.txt- STRUCTURE MOUNT (SMNT)
../data/rfc/rfc959.txt-
../data/rfc/rfc959.txt- This command allows the user to mount a different file
../data/rfc/rfc959.txt- system data structure without altering his login or
../data/rfc/rfc959.txt: accounting information. Transfer parameters are similarly
../data/rfc/rfc959.txt- unchanged. The argument is a pathname specifying a
../data/rfc/rfc959.txt- directory or other system dependent file group designator.
../data/rfc/rfc959.txt-
../data/rfc/rfc959.txt- REINITIALIZE (REIN)
../data/rfc/rfc959.txt-
--
../data/rfc/rfc959.txt- information, such as status or help.
../data/rfc/rfc959.txt-
../data/rfc/rfc959.txt- x2z Connections - Replies referring to the control and
../data/rfc/rfc959.txt- data connections.
../data/rfc/rfc959.txt-
../data/rfc/rfc959.txt: x3z Authentication and accounting - Replies for the login
../data/rfc/rfc959.txt: process and accounting procedures.
../data/rfc/rfc959.txt-
../data/rfc/rfc959.txt- x4z Unspecified as yet.
../data/rfc/rfc959.txt-
../data/rfc/rfc959.txt- x5z File system - These replies indicate the status of the
../data/rfc/rfc959.txt- Server file system vis-a-vis the requested transfer or
--
../data/rfc/rfc7499.txt-
../data/rfc/rfc7499.txt-
../data/rfc/rfc7499.txt-1. Introduction
../data/rfc/rfc7499.txt-
../data/rfc/rfc7499.txt- The RADIUS [RFC2865] protocol carries authentication, authorization,
../data/rfc/rfc7499.txt: and accounting information between a RADIUS Client and a RADIUS
../data/rfc/rfc7499.txt- Server. Information is exchanged between them through RADIUS
../data/rfc/rfc7499.txt- packets. Each RADIUS packet is composed of a header, and zero or
../data/rfc/rfc7499.txt- more attributes, up to a maximum packet size of 4096 bytes. The
../data/rfc/rfc7499.txt- protocol is a request/response protocol, as described in the
../data/rfc/rfc7499.txt- operational model ([RFC6158], Section 3.1).
--
../data/rfc/rfc7499.txt-
../data/rfc/rfc7499.txt- This means that peers desiring to send large amounts of data must
../data/rfc/rfc7499.txt- fragment it across multiple packets. For example, RADIUS-EAP
../data/rfc/rfc7499.txt- [RFC3579] defines how an Extensible Authentication Protocol (EAP)
../data/rfc/rfc7499.txt- exchange occurs across multiple Access-Request / Access-Challenge
../data/rfc/rfc7499.txt: sequences. No such exchange is possible for accounting or
../data/rfc/rfc7499.txt- authorization data. [RFC6158], Section 3.1 suggests that exchanging
../data/rfc/rfc7499.txt- large amounts of authorization data is unnecessary in RADIUS.
../data/rfc/rfc7499.txt- Instead, the data should be referenced by name. This requirement
../data/rfc/rfc7499.txt- allows large policies to be pre-provisioned and then referenced in an
../data/rfc/rfc7499.txt- Access-Accept. In some cases, however, the authorization data sent
--
../data/rfc/rfc7499.txt- limitation (e.g., RADIUS-EAP). Moreover, as they represent the most
../data/rfc/rfc7499.txt- critical part of a RADIUS conversation, it is preferable to not
../data/rfc/rfc7499.txt- introduce into their operation any modification that may affect
../data/rfc/rfc7499.txt- existing equipment.
../data/rfc/rfc7499.txt-
../data/rfc/rfc7499.txt: There is no need to fragment accounting packets either. While the
../data/rfc/rfc7499.txt: accounting process can send large amounts of data, that data is
../data/rfc/rfc7499.txt- typically composed of many small updates. That is, there is no
../data/rfc/rfc7499.txt- demonstrated need to send indivisible blocks of more than 4 kilobytes
../data/rfc/rfc7499.txt- of data. The need to send large amounts of data per user session
../data/rfc/rfc7499.txt: often originates from the need for flow-based accounting. In this
../data/rfc/rfc7499.txt: use case, the RADIUS Client may send accounting data for many
../data/rfc/rfc7499.txt- thousands of flows, where all those flows are tied to one user
../data/rfc/rfc7499.txt- session. The existing Acct-Multi-Session-Id attribute defined in
../data/rfc/rfc7499.txt- [RFC2866], Section 5.11 has been proven to work here.
../data/rfc/rfc7499.txt-
../data/rfc/rfc7499.txt- Similarly, there is no need to fragment Change-of-Authorization (CoA)
--
../data/rfc/rfc7499.txt-
../data/rfc/rfc7499.txt- The bulk data can often be pushed off to storage methods other than
../data/rfc/rfc7499.txt- the memory of the RADIUS implementation. For example, it can be
../data/rfc/rfc7499.txt- stored in an external database or in files. This approach mitigates
../data/rfc/rfc7499.txt- the resource exhaustion issue, as RADIUS Servers today already store
../data/rfc/rfc7499.txt: large amounts of accounting data.
../data/rfc/rfc7499.txt-
../data/rfc/rfc7499.txt-
../data/rfc/rfc7499.txt-
../data/rfc/rfc7499.txt-
../data/rfc/rfc7499.txt-
--
../data/rfc/rfc7499.txt-
../data/rfc/rfc7499.txt- [RADIUS-Larger-Pkts]
../data/rfc/rfc7499.txt- Hartman, S., "Larger Packets for RADIUS over TCP", Work in
../data/rfc/rfc7499.txt- Progress, draft-ietf-radext-bigger-packets-03, March 2015.
../data/rfc/rfc7499.txt-
../data/rfc/rfc7499.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000,
../data/rfc/rfc7499.txt- <http://www.rfc-editor.org/info/rfc2866>.
../data/rfc/rfc7499.txt-
../data/rfc/rfc7499.txt- [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
../data/rfc/rfc7499.txt- Dial In User Service) Support For Extensible
../data/rfc/rfc7499.txt- Authentication Protocol (EAP)", RFC 3579, September 2003,
--
../data/rfc/rfc5116.txt- user of the application and the VM avoid unintentional mistakes of
../data/rfc/rfc5116.txt- this sort. The possibility exists that an attacker can cause a VM
../data/rfc/rfc5116.txt- rollback; threats and mitigations in that scenario are an area of
../data/rfc/rfc5116.txt- active research. For perspective, we note that an attacker who can
../data/rfc/rfc5116.txt- trigger such a rollback may have already succeeded in subverting the
../data/rfc/rfc5116.txt: security of the system, e.g., by causing an accounting error.
../data/rfc/rfc5116.txt-
../data/rfc/rfc5116.txt- An IANA registration of an AEAD algorithm MUST NOT be regarded as an
../data/rfc/rfc5116.txt- endorsement of its security. Furthermore, the perceived security
../data/rfc/rfc5116.txt- level of an algorithm can degrade over time, due to cryptanalytic
../data/rfc/rfc5116.txt- advances or to "Moore's Law", that is, the diminishing cost of
--
../data/rfc/rfc6035.txt-; using the ABNF format provided in RFC 3339,
../data/rfc/rfc6035.txt-; "Date and Time on the Internet: Timestamps"
../data/rfc/rfc6035.txt-; These timestamps SHOULD reflect, as closely as
../data/rfc/rfc6035.txt-; possible, the actual time during which the media session
../data/rfc/rfc6035.txt-; was running to enable correlation to events occurring
../data/rfc/rfc6035.txt:; in the network infrastructure and to accounting records.
../data/rfc/rfc6035.txt-; Time zones other than "Z" are not allowed.
../data/rfc/rfc6035.txt-
../data/rfc/rfc6035.txt-TimeStamps = "Timestamps" HCOLON StartTime WSP StopTime
../data/rfc/rfc6035.txt-StartTime = "START" EQUAL date-time
../data/rfc/rfc6035.txt-StopTime = "STOP" EQUAL date-time
--
../data/rfc/rfc6035.txt- Following SIP and other IETF conventions, timestamps are provided in
../data/rfc/rfc6035.txt- Coordinated Universal Time (UTC) using the ABNF format provided in
../data/rfc/rfc6035.txt- RFC 3339 [7]. These timestamps SHOULD reflect, as closely as
../data/rfc/rfc6035.txt- possible, the actual time during which the media session was running
../data/rfc/rfc6035.txt- to enable correlation to related events occurring in the network and
../data/rfc/rfc6035.txt: to accounting or billing records.
../data/rfc/rfc6035.txt-
../data/rfc/rfc6035.txt-
../data/rfc/rfc6035.txt-
../data/rfc/rfc6035.txt-
../data/rfc/rfc6035.txt-Pendleton, et al. Standards Track [Page 21]
--
../data/rfc/rfc5690.txt- will not necessarily be able to tell if ACK congestion control is
../data/rfc/rfc5690.txt- being used correctly by the sender, because drops of ACK packets
../data/rfc/rfc5690.txt- might be occurring after the ACK packets have left the router.
../data/rfc/rfc5690.txt- However, if the router sees the ACK Ratio options sent from the
../data/rfc/rfc5690.txt- sender, the router will be able to tell if the sender is correctly
../data/rfc/rfc5690.txt: accounting for those ACK packets that are dropped or ECN-marked on
../data/rfc/rfc5690.txt- the path from the receiver to the router.
../data/rfc/rfc5690.txt-
../data/rfc/rfc5690.txt-10. IANA Considerations
../data/rfc/rfc5690.txt-
../data/rfc/rfc5690.txt- No IANA action is needed at this time. If this document was advanced
--
../data/rfc/rfc7620.txt-
../data/rfc/rfc7620.txt-
../data/rfc/rfc7620.txt- * The provider is not able to distinguish the traffic belonging
../data/rfc/rfc7620.txt- to the visiting terminal from the traffic of the subscriber
../data/rfc/rfc7620.txt- owning the RG. This is needed to identify which policies are
../data/rfc/rfc7620.txt: to be enforced such as: accounting, Differentiated Services
../data/rfc/rfc7620.txt- Code Point (DSCP) remarking, black list, etc.
../data/rfc/rfc7620.txt-
../data/rfc/rfc7620.txt- * Similar to the CGN case Section 3, a misbehaving visiting
../data/rfc/rfc7620.txt- terminal is likely to have some impact on the experienced
../data/rfc/rfc7620.txt- service by the subscriber owning the RG (e.g., some of the
--
../data/rfc/rfc7620.txt- SeGW would have the complete knowledge of such mapping, but the
../data/rfc/rfc7620.txt- reasons for being unable to use SeGW for this purpose are explained
../data/rfc/rfc7620.txt- in Section 2 of [IKEv2-CP-EXT].
../data/rfc/rfc7620.txt-
../data/rfc/rfc7620.txt- This scenario involves PCRF/BPCF, but it is valid in other deployment
../data/rfc/rfc7620.txt: scenarios making use of Authentication, Authorization, and Accounting
../data/rfc/rfc7620.txt- (AAA) servers.
../data/rfc/rfc7620.txt-
../data/rfc/rfc7620.txt- The issue of correlating the internal IP address and the public IP
../data/rfc/rfc7620.txt- address is valid even if there is no NAT in the path.
../data/rfc/rfc7620.txt-
--
../data/rfc/rfc7620.txt-
../data/rfc/rfc7620.txt- In the Policy for Convergence of Fixed Mobile Convergence (FMC)
../data/rfc/rfc7620.txt- scenario, the fixed broadband network must partner with the mobile
../data/rfc/rfc7620.txt- network to acquire the policies for the terminals or hosts attaching
../data/rfc/rfc7620.txt- to the fixed broadband network, shown in Figure 15, so that host-
../data/rfc/rfc7620.txt: specific QoS and accounting policies can be applied.
../data/rfc/rfc7620.txt-
../data/rfc/rfc7620.txt- A UE is connected to the RG, which is routed back to the mobile
../data/rfc/rfc7620.txt- network. The mobile operator's PCRF needs to maintain the
../data/rfc/rfc7620.txt- interconnect with the BPCF in the BBF network for PCC (Section 8).
../data/rfc/rfc7620.txt- The hosts (i.e., UEs) attaching to a fixed broadband network with a
--
../data/rfc/rfc7620.txt-
../data/rfc/rfc7620.txt- HOST_1 in Figure 16 creates a 128-bit IPv6 address using this prefix
../data/rfc/rfc7620.txt- and adding its interface ID. Having completed the address
../data/rfc/rfc7620.txt- configuration, the host can start communication with a remote host
../data/rfc/rfc7620.txt- over the Internet. However, no specific IP-CAN session can be
../data/rfc/rfc7620.txt: assigned to HOST_1, and consequently the QoS and accounting performed
../data/rfc/rfc7620.txt- will be based on RG subscription.
../data/rfc/rfc7620.txt-
../data/rfc/rfc7620.txt- Another host, e.g., HOST_2, attaches to the RG and also establishes
../data/rfc/rfc7620.txt- an IPv6 address using the home network prefix. The edge router, or
../data/rfc/rfc7620.txt- BNG, is not involved with this or any other such address assignments.
../data/rfc/rfc7620.txt-
../data/rfc/rfc7620.txt- This leads to the case where no specific IP-CAN session/sub-session
../data/rfc/rfc7620.txt- can be assigned to the hosts, HOST_1, HOST_2, etc., and consequently
../data/rfc/rfc7620.txt: the QoS and accounting performed can only be based on RG subscription
../data/rfc/rfc7620.txt- and is not host specific. Therefore, IPv6 prefix sharing in the
../data/rfc/rfc7620.txt- Policy for Convergence scenario leads to similar issues as the
../data/rfc/rfc7620.txt-
../data/rfc/rfc7620.txt-
../data/rfc/rfc7620.txt-
--
../data/rfc/rfc1927.txt- so a supply of staples could be used be used by several
../data/rfc/rfc1927.txt- programs.
../data/rfc/rfc1927.txt-
../data/rfc/rfc1927.txt-3) recycling electronic staples and paper clips
../data/rfc/rfc1927.txt-
../data/rfc/rfc1927.txt: 1) to assure proper accounting, and to detect patent violations
../data/rfc/rfc1927.txt- (people making their own electronic staples), it may be
../data/rfc/rfc1927.txt- necessary to attach a certificate to each staple or paper
../data/rfc/rfc1927.txt- clip.
../data/rfc/rfc1927.txt-
../data/rfc/rfc1927.txt-
--
../data/rfc/rfc4640.txt-
../data/rfc/rfc4640.txt-RFC 4640 PS Bootstrapping Mobile IPv6 September 2006
../data/rfc/rfc4640.txt-
../data/rfc/rfc4640.txt-
../data/rfc/rfc4640.txt- One typical way of verifying the trust relationship is using
../data/rfc/rfc4640.txt: authentication, authorization, and accounting (AAA)
../data/rfc/rfc4640.txt- infrastructure. In this document, two distinct uses of AAA are
../data/rfc/rfc4640.txt- considered:
../data/rfc/rfc4640.txt-
../data/rfc/rfc4640.txt- AAA for Network Access
../data/rfc/rfc4640.txt-
--
../data/rfc/rfc4640.txt-
../data/rfc/rfc4640.txt-5.2.1. Integration with AAA Infrastructure
../data/rfc/rfc4640.txt-
../data/rfc/rfc4640.txt- The current IKEv1-based dynamic key exchange protocol, described in
../data/rfc/rfc4640.txt- [RFC3776], has no integration with backend authentication,
../data/rfc/rfc4640.txt: authorization, and accounting techniques unless the authentication
../data/rfc/rfc4640.txt- credentials and trust relationships use certificates or pre-shared
../data/rfc/rfc4640.txt- secrets.
../data/rfc/rfc4640.txt-
../data/rfc/rfc4640.txt- Certificates are not easily supported by traditional AAA
../data/rfc/rfc4640.txt- infrastructures. Where a traditional AAA infrastructure is used, the
--
../data/rfc/rfc4640.txt- mobile node gains access to the foreign network, in order to
../data/rfc/rfc4640.txt- authenticate the mobile node's identity and determine whether the
../data/rfc/rfc4640.txt- mobile node is authorized for mobility service.
../data/rfc/rfc4640.txt-
../data/rfc/rfc4640.txt- The lack of connection to the AAA infrastructure also means that the
../data/rfc/rfc4640.txt: home agent does not know where to send accounting records at
../data/rfc/rfc4640.txt- appropriate times during the mobile node's session, as determined by
../data/rfc/rfc4640.txt- the business relationship between the MSP and the mobile node's
../data/rfc/rfc4640.txt- owner.
../data/rfc/rfc4640.txt-
../data/rfc/rfc4640.txt- Presumably, some backend AAA protocol between the home agent and home
--
../data/rfc/rfc3199.txt-
../data/rfc/rfc3199.txt-3141 Hiller Jun 2001 CDMA2000 Wireless Data
../data/rfc/rfc3199.txt- Requirements for AAA
../data/rfc/rfc3199.txt-
../data/rfc/rfc3199.txt-This memo specifies cdma2000 wireless data AAA (Authentication,
../data/rfc/rfc3199.txt:Authorization, Accounting) requirements associated with third generation
../data/rfc/rfc3199.txt-wireless architecture that supports roaming among service providers for
../data/rfc/rfc3199.txt-traditional PPP and Mobile IP services. This memo provides information
../data/rfc/rfc3199.txt-for the Internet community.
../data/rfc/rfc3199.txt-
../data/rfc/rfc3199.txt-
--
../data/rfc/rfc3199.txt-
../data/rfc/rfc3199.txt-RFC 3199 Summary of 3100-3199 February 2003
../data/rfc/rfc3199.txt-
../data/rfc/rfc3199.txt-
../data/rfc/rfc3199.txt-3127 Mitton Jun 2001 Authentication, Authorization,
../data/rfc/rfc3199.txt: and Accounting: Protocol
../data/rfc/rfc3199.txt- Evaluation
../data/rfc/rfc3199.txt-
../data/rfc/rfc3199.txt-This memo represents the process and findings of the Authentication,
../data/rfc/rfc3199.txt:Authorization, and Accounting Working Group (AAA WG) panel evaluating
../data/rfc/rfc3199.txt-protocols proposed against the AAA Network Access Requirements, RFC
../data/rfc/rfc3199.txt-2989. This memo provides information for the Internet community.
../data/rfc/rfc3199.txt-
../data/rfc/rfc3199.txt-
../data/rfc/rfc3199.txt-3126 Pinkas Sep 2001 Electronic Signature Formats
--
../data/rfc/rfc6272.txt- 2.3. Network Infrastructure . . . . . . . . . . . . . . . . . . 13
../data/rfc/rfc6272.txt- 2.3.1. Domain Name System (DNS) . . . . . . . . . . . . . . . 13
../data/rfc/rfc6272.txt- 2.3.2. Network Management . . . . . . . . . . . . . . . . . . 13
../data/rfc/rfc6272.txt- 3. Specific Protocols . . . . . . . . . . . . . . . . . . . . . . 14
../data/rfc/rfc6272.txt- 3.1. Security Toolbox . . . . . . . . . . . . . . . . . . . . . 14
../data/rfc/rfc6272.txt: 3.1.1. Authentication, Authorization, and Accounting (AAA) . 14
../data/rfc/rfc6272.txt- 3.1.2. Network Layer Security . . . . . . . . . . . . . . . . 15
../data/rfc/rfc6272.txt- 3.1.3. Transport Layer Security . . . . . . . . . . . . . . . 16
../data/rfc/rfc6272.txt- 3.1.4. Application Layer Security . . . . . . . . . . . . . . 17
../data/rfc/rfc6272.txt- 3.1.5. Secure Shell . . . . . . . . . . . . . . . . . . . . . 18
../data/rfc/rfc6272.txt- 3.1.6. Key Management Infrastructures . . . . . . . . . . . . 18
--
../data/rfc/rfc6272.txt-
../data/rfc/rfc6272.txt- In this section, having briefly laid out the IP architecture and some
../data/rfc/rfc6272.txt- of the problems that the architecture tries to address, we introduce
../data/rfc/rfc6272.txt- specific protocols that might be appropriate to various Smart Grid
../data/rfc/rfc6272.txt- use cases. Use cases should be analyzed along with privacy,
../data/rfc/rfc6272.txt: Authentication, Authorization, and Accounting (AAA), transport, and
../data/rfc/rfc6272.txt- network solution dimensions. The following sections provide guidance
../data/rfc/rfc6272.txt- for such analysis.
../data/rfc/rfc6272.txt-
../data/rfc/rfc6272.txt-3.1. Security Toolbox
../data/rfc/rfc6272.txt-
--
../data/rfc/rfc6272.txt- specifically designed to mitigate these protocol-specific risks. In
../data/rfc/rfc6272.txt- other cases, the security considerations will identify security-
../data/rfc/rfc6272.txt- relevant services that are required from other network layers to
../data/rfc/rfc6272.txt- achieve appropriate levels of security.
../data/rfc/rfc6272.txt-
../data/rfc/rfc6272.txt:3.1.1. Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc6272.txt-
../data/rfc/rfc6272.txt- While the term AAA sounds generic and applicable to all sorts of
../data/rfc/rfc6272.txt- security protocols, it has been, in the IETF, used in relation to
../data/rfc/rfc6272.txt- network access authentication and is associated with the RADIUS
../data/rfc/rfc6272.txt- ([RFC2865]) and the Diameter protocol ([RFC3588], [DIME-BASE]) in
--
../data/rfc/rfc6272.txt- cryptographic authentication and key exchange, such as described in
../data/rfc/rfc6272.txt- RFC 5216 [RFC5216] and RFC 5433 [RFC5433]), a protocol that carries
../data/rfc/rfc6272.txt- EAP payloads between the end host and a server-side entity (such as a
../data/rfc/rfc6272.txt- network access server), and a way to carry EAP payloads to back-end
../data/rfc/rfc6272.txt- server infrastructure (potentially in a cross-domain scenario) to
../data/rfc/rfc6272.txt: provide authorization and accounting functionality. The latter part
../data/rfc/rfc6272.txt- is provided by RADIUS and Diameter. To carry EAP payloads between
../data/rfc/rfc6272.txt- the end host and a network access server, different mechanisms have
../data/rfc/rfc6272.txt- been standardized, such as the Protocol for Carrying Authentication
../data/rfc/rfc6272.txt- for Network Access (PANA) [RFC5191] and IEEE 802.1X [IEEE802.1X].
../data/rfc/rfc6272.txt- For access to remote networks, such as enterprise networks, the
--
../data/rfc/rfc9005.txt-3. Motivation
../data/rfc/rfc9005.txt-
../data/rfc/rfc9005.txt- Paths computed using PCE can be subjected to various policies at both
../data/rfc/rfc9005.txt- the PCE and the PCC. For example, in a centralized TE scenario,
../data/rfc/rfc9005.txt- network operators may instantiate LSPs and specify policies for
../data/rfc/rfc9005.txt: traffic accounting, path monitoring, telemetry, etc., for some LSPs
../data/rfc/rfc9005.txt- via the stateful PCE. Similarly, a PCC could request a user-specific
../data/rfc/rfc9005.txt- or service-specific policy to be applied at the PCE, such as a
../data/rfc/rfc9005.txt- constraints relaxation policy, to meet optimal QoS and resiliency
../data/rfc/rfc9005.txt- levels.
../data/rfc/rfc9005.txt-
--
../data/rfc/rfc3374.txt- In IP access networks that support host mobility, the routing paths
../data/rfc/rfc3374.txt- between the host and the network may change frequently and rapidly.
../data/rfc/rfc3374.txt- In some cases, the host may establish certain context transfer
../data/rfc/rfc3374.txt- candidate services on subnets that are left behind when the host
../data/rfc/rfc3374.txt- moves. Examples of such services are Authentication, Authorization,
../data/rfc/rfc3374.txt: and Accounting (AAA), header compression, and Quality of Service
../data/rfc/rfc3374.txt- (QoS). In order for the host to obtain those services on the new
../data/rfc/rfc3374.txt- subnet, the host must explicitly re-establish the service by
../data/rfc/rfc3374.txt- performing the necessary signaling flows from scratch. In some
../data/rfc/rfc3374.txt- cases, this process would considerably slow the process of
../data/rfc/rfc3374.txt- establishing the mobile host on the new subnet. An alternative is to
--
../data/rfc/rfc3374.txt- 1.0 Introduction................................................2
../data/rfc/rfc3374.txt- 2.0 Reference Definitions.......................................3
../data/rfc/rfc3374.txt- 3.0 Scope of the Context Transfer Problem.......................3
../data/rfc/rfc3374.txt- 4.0 The Need for Context Transfer...............................4
../data/rfc/rfc3374.txt- 4.1 Fast Context Transfer-candidate Service Re-establishment....4
../data/rfc/rfc3374.txt: 4.1.1 Authentication, Authorization, and Accounting (AAA).........4
../data/rfc/rfc3374.txt- 4.1.2 Header Compression..........................................5
../data/rfc/rfc3374.txt- 4.1.3 Quality of Service (QoS)....................................6
../data/rfc/rfc3374.txt- 4.2 Interoperability............................................6
../data/rfc/rfc3374.txt- 5.0 Limitations on Context Transfer.............................7
../data/rfc/rfc3374.txt- 5.1 Router Compatibility........................................7
--
../data/rfc/rfc3374.txt- transfer-candidate services that could utilize a context transfer
../data/rfc/rfc3374.txt- solution. In this section, three representative services are
../data/rfc/rfc3374.txt- examined. The consequences of not having a context transfer solution
../data/rfc/rfc3374.txt- are examined as a means of motivating the need for such a solution.
../data/rfc/rfc3374.txt-
../data/rfc/rfc3374.txt:4.1.1 Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc3374.txt-
../data/rfc/rfc3374.txt- One of the more compelling applications of context transfer is
../data/rfc/rfc3374.txt- facilitating the re-authentication of the mobile host and
../data/rfc/rfc3374.txt- re-establishment of the mobile host's authorization for network
../data/rfc/rfc3374.txt- access in a new subnet by transferring the AAA context from the
--
../data/rfc/rfc6136.txt-
../data/rfc/rfc6136.txt- The scope of OAM for any service and/or transport/network
../data/rfc/rfc6136.txt- infrastructure technologies can be very broad in nature. OSI has
../data/rfc/rfc6136.txt- defined the following five generic functional areas commonly
../data/rfc/rfc6136.txt- abbreviated as "FCAPS" [NM-Standards]: a) Fault Management, b)
../data/rfc/rfc6136.txt: Configuration Management, c) Accounting Management, d) Performance
../data/rfc/rfc6136.txt- Management, and e) Security Management.
../data/rfc/rfc6136.txt-
../data/rfc/rfc6136.txt-
../data/rfc/rfc6136.txt-
../data/rfc/rfc6136.txt-
--
../data/rfc/rfc759.txt- 3.6. Message Objects ............................................. 20
../data/rfc/rfc759.txt- 3.7. Data Elements ............................................... 27
../data/rfc/rfc759.txt-
../data/rfc/rfc759.txt-4. OTHER ISSUES .................................................... 35
../data/rfc/rfc759.txt-
../data/rfc/rfc759.txt: 4.1. Accounting and Billing ...................................... 35
../data/rfc/rfc759.txt- 4.2. Addressing and Routing ...................................... 36
../data/rfc/rfc759.txt- 4.3. Encryption .................................................. 37
../data/rfc/rfc759.txt-
../data/rfc/rfc759.txt-5. The MPM: A Possible Architecture ............................... 39
../data/rfc/rfc759.txt-
--
../data/rfc/rfc759.txt- 4. OTHER ISSUES
../data/rfc/rfc759.txt-
../data/rfc/rfc759.txt-This section discusses various other issues that need to be dealt with
../data/rfc/rfc759.txt-in a computer message system.
../data/rfc/rfc759.txt-
../data/rfc/rfc759.txt:4.1. Accounting and Billing
../data/rfc/rfc759.txt-
../data/rfc/rfc759.txt: Accounting and billing must be performed by the MPM. The charge to
../data/rfc/rfc759.txt- the user by the message delivery system must be predictable, and so
../data/rfc/rfc759.txt- cannot depend on the actual cost of sending a particular message which
../data/rfc/rfc759.txt- incurs random delays, handling and temporary storage charges. Rather,
../data/rfc/rfc759.txt- these costs must be aggregated and charged back to the users on an
../data/rfc/rfc759.txt- average cost basis. The user of the service may be charged based on
--
../data/rfc/rfc5254.txt- For SS-PWs, a traffic engineered PSN tunnel (i.e., MPLS-TE) may be
../data/rfc/rfc5254.txt- used to ensure that sufficient resources are reserved in the
../data/rfc/rfc5254.txt- P-routers to provide QoS to PWs on the tunnel. In this case, T-PEs
../data/rfc/rfc5254.txt- MUST have the ability to automatically request the PSN tunnel
../data/rfc/rfc5254.txt- resources in the direction of traffic (e.g., admission control of PWs
../data/rfc/rfc5254.txt: onto the PSN tunnel and accounting for reserved bandwidth and
../data/rfc/rfc5254.txt-
../data/rfc/rfc5254.txt-
../data/rfc/rfc5254.txt-
../data/rfc/rfc5254.txt-Bitar, et al. Informational [Page 11]
../data/rfc/rfc5254.txt-
--
../data/rfc/rfc790.txt- 83 123 MIT ML Device [MOON]
../data/rfc/rfc790.txt- 85 125 MIT ML Device [MOON]
../data/rfc/rfc790.txt- 87 127 any terminal link [JBP]
../data/rfc/rfc790.txt- 89 131 SU/MIT Telnet Gateway [MRC]
../data/rfc/rfc790.txt- 91 133 MIT Dover Spooler [EBM]
../data/rfc/rfc790.txt: 93 135 BBN RCC Accounting [DT]
../data/rfc/rfc790.txt- 95 137 SUPDUP [15,MRC]
../data/rfc/rfc790.txt- 97 141 Datacomputer Status [8,JZS]
../data/rfc/rfc790.txt- 99 143 CADC - NIFTP via UCL [PLH]
../data/rfc/rfc790.txt- 101 145 NPL - NIFTP via UCL [PLH]
../data/rfc/rfc790.txt- 103 147 BNPL - NIFTP via UCL [PLH]
--
../data/rfc/rfc790.txt- 2-71 2-107 AHHP Regular Messages [28,17,JBP]
../data/rfc/rfc790.txt- 72-150 110-226 Reserved [JBP]
../data/rfc/rfc790.txt- 151 227 CHAOS Protocol [MOON]
../data/rfc/rfc790.txt- 152 230 PARC Universal Protocol [4,EAT3]
../data/rfc/rfc790.txt- 153 231 TIP Status Reporting [JGH]
../data/rfc/rfc790.txt: 154 232 TIP Accounting [JGH]
../data/rfc/rfc790.txt- 155 233 Internet Protocol (regular) [33,JBP]
../data/rfc/rfc790.txt- 156-158 234-236 Internet Protocol (experimental) [33,JBP]
../data/rfc/rfc790.txt- 159-191 237-277 Measurements [9,VGC]
../data/rfc/rfc790.txt- 192-195 300-303 Unassigned [JBP]
../data/rfc/rfc790.txt- 196-255 304-377 Experimental Protocols [JBP]
--
../data/rfc/rfc7542.txt- "Local" or "Localized" Text
../data/rfc/rfc7542.txt-
../data/rfc/rfc7542.txt- "Local" or "localized" text is text that is in either non-UTF-8 or
../data/rfc/rfc7542.txt- non-normalized form. The character set, encoding, and locale are
../data/rfc/rfc7542.txt- (in general) unknown to Authentication, Authorization, and
../data/rfc/rfc7542.txt: Accounting (AAA) network protocols. The client that "knows" the
../data/rfc/rfc7542.txt- locale may have a different concept of this text than other AAA
../data/rfc/rfc7542.txt- entities, which do not know the same locale.
../data/rfc/rfc7542.txt-
../data/rfc/rfc7542.txt- Network Access Identifier
../data/rfc/rfc7542.txt-
--
../data/rfc/rfc7542.txt-
../data/rfc/rfc7542.txt- * The prohibition of the use of unassigned code points in
../data/rfc/rfc7542.txt- Section 2.4 of [RFC4282] effectively prohibits support for new
../data/rfc/rfc7542.txt- scripts.
../data/rfc/rfc7542.txt-
../data/rfc/rfc7542.txt: * No Authentication, Authorization, and Accounting (AAA) client,
../data/rfc/rfc7542.txt- proxy, or server has implemented any of the requirements in
../data/rfc/rfc7542.txt- Section 2.4 of [RFC4282], among other sections.
../data/rfc/rfc7542.txt-
../data/rfc/rfc7542.txt- With international roaming growing in popularity, it is important for
../data/rfc/rfc7542.txt- these issues to be corrected in order to provide robust and
--
../data/rfc/rfc7542.txt- these requirements.
../data/rfc/rfc7542.txt-
../data/rfc/rfc7542.txt- One example of such use is the "private user identity", which is an
../data/rfc/rfc7542.txt- identifier defined by the 3rd Generation Partnership Project (3GPP).
../data/rfc/rfc7542.txt- That identifier is used to uniquely identify the user to the network.
../data/rfc/rfc7542.txt: The identifier is used for authorization, authentication, accounting,
../data/rfc/rfc7542.txt- administration, etc. The "private user identity" is globally unique
../data/rfc/rfc7542.txt- and is defined by the home network operator. The format of the
../data/rfc/rfc7542.txt- identifier is explicitly the NAI, as stated by Section 13.3 of
../data/rfc/rfc7542.txt- [3GPP]:
../data/rfc/rfc7542.txt-
--
../data/rfc/rfc7542.txt- [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
../data/rfc/rfc7542.txt- "Remote Authentication Dial In User Service (RADIUS)",
../data/rfc/rfc7542.txt- RFC 2865, June 2000,
../data/rfc/rfc7542.txt- <http://www.rfc-editor.org/info/rfc2865>.
../data/rfc/rfc7542.txt-
../data/rfc/rfc7542.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000,
../data/rfc/rfc7542.txt- <http://www.rfc-editor.org/info/rfc2866>.
../data/rfc/rfc7542.txt-
../data/rfc/rfc7542.txt- [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
../data/rfc/rfc7542.txt- for Internationalized Domain Names in Applications
../data/rfc/rfc7542.txt- (IDNA)", RFC 3492, March 2003,
--
../data/rfc/rfc666.txt- it would be unworkable as well as ill-advised to attempt to legislate
../data/rfc/rfc666.txt- the richness represented by existing command languages out of
../data/rfc/rfc666.txt- existence. Further, as it is a closed environment, no naming
../data/rfc/rfc666.txt- conflicts with native commands would arise.
../data/rfc/rfc666.txt-
../data/rfc/rfc666.txt: 5. Accounting and authentication. As evidenced by the spate of RFCs
../data/rfc/rfc666.txt: about the implications of the FTP in regard to both accounting for
../data/rfc/rfc666.txt- use of Network services and authenticating users' identifications
../data/rfc/rfc666.txt- (Bressler's RFC 487, Pogran's RFC 501, and my RFC 505 -- and even
../data/rfc/rfc666.txt- 491), this area is still up in the air. The generic login command
../data/rfc/rfc666.txt- proposed here should help matters, as it allows the Server to
../data/rfc/rfc666.txt- associate an appropriate process with the connection while actuating
../data/rfc/rfc666.txt: appropriate accounting and access control as well, if it chooses.
../data/rfc/rfc666.txt-
../data/rfc/rfc666.txt- 6. Process-process functions. By enabling the invocation of foreign
../data/rfc/rfc666.txt- object programs, the present proposal offers a rubric in which such
../data/rfc/rfc666.txt- process-to-process functions as "parallelism" can be performed. (See
../data/rfc/rfc666.txt- the discussion of the "call" command, below.) Note that the UULP is
--
../data/rfc/rfc82.txt-Meyer [Page 2]
../data/rfc/rfc82.txt-
../data/rfc/rfc82.txt-RFC 82 Network Meeting Notes December 1970
../data/rfc/rfc82.txt-
../data/rfc/rfc82.txt-
../data/rfc/rfc82.txt: 6) Accounting - In the 2nd half of 1971 more sites will come on
../data/rfc/rfc82.txt: where accounting is important. (They want to send bills.)
../data/rfc/rfc82.txt- Larry Roberts says that there will be a kind of banking system
../data/rfc/rfc82.txt- with bills passed around. Two types of sites: billing sites,
../data/rfc/rfc82.txt- and free but limited access research sites. I see no
../data/rfc/rfc82.txt- fundamental problems. What happens when a research site talks
../data/rfc/rfc82.txt- to a billing site? I think it is do-able.
--
../data/rfc/rfc82.txt- that is better than a simulation package. Various people want
../data/rfc/rfc82.txt- to make measurements. This could be supported by keeping
../data/rfc/rfc82.txt- statistics in NCP's What about increasing the NCP's to include
../data/rfc/rfc82.txt- these?
../data/rfc/rfc82.txt-
../data/rfc/rfc82.txt: Long: Putting accounting and measuring into NCP's costs space. Keep
../data/rfc/rfc82.txt- additions to a minimum.
../data/rfc/rfc82.txt-
../data/rfc/rfc82.txt- Weissman: What about scheduled availability of various systems?
../data/rfc/rfc82.txt-
../data/rfc/rfc82.txt- Crocker: This has to be coordinated with each individual system
--
../data/rfc/rfc82.txt- Engelbart: If BBN's NCP is ready by February 1971, we'll use it.
../data/rfc/rfc82.txt-
../data/rfc/rfc82.txt- Crocker: How do people get access?
../data/rfc/rfc82.txt-
../data/rfc/rfc82.txt- Engelbart: Each site is registered. Any person who gets in on a
../data/rfc/rfc82.txt: site's account has its access. We won't worry about accounting
../data/rfc/rfc82.txt- until saturation occurs. We would like to encourage use of the
../data/rfc/rfc82.txt- agent system to create and use a survey of resources at each site.
../data/rfc/rfc82.txt- Some subgroup should talk about this.
../data/rfc/rfc82.txt-
../data/rfc/rfc82.txt- Crocker: When can people meet to discuss this? (Tomorrow morning)
--
../data/rfc/rfc2600.txt-WEBDAV HTTP Extensions for Distributed Authoring -- WEBDAV 2518
../data/rfc/rfc2600.txt-ATM-MIBMAN Definitions of Managed Objects for ATM Management 2515
../data/rfc/rfc2600.txt-ATM-TC-OID Definitions of Textual Conventions and 2514
../data/rfc/rfc2600.txt- OBJECT-IDENTITIES for ATM Management
../data/rfc/rfc2600.txt--------- Managed Objects for Controlling the Collection 2513
../data/rfc/rfc2600.txt: and Storage of Accounting Information for
../data/rfc/rfc2600.txt- Connection-Oriented Networks
../data/rfc/rfc2600.txt:-------- Accounting Information for ATM Networks 2512
../data/rfc/rfc2600.txt-X.509-CRMF Internet X.509 Certificate Request Message Format 2511
../data/rfc/rfc2600.txt-PKICMP Internet X.509 Public Key Infrastructure Certificate 2510
../data/rfc/rfc2600.txt- Management Protocols
../data/rfc/rfc2600.txt-IPCOM-PPP IP Header Compression over PPP 2509
../data/rfc/rfc2600.txt--------- Compressing IP/UDP/RTP Headers for Low-Speed Serial 2508
--
../data/rfc/rfc6310.txt-A.2. ATM Management
../data/rfc/rfc6310.txt-
../data/rfc/rfc6310.txt- ATM management and OAM mechanisms are much more evolved than those of
../data/rfc/rfc6310.txt- Frame Relay. There are five broad management-related categories,
../data/rfc/rfc6310.txt- including fault management (FT), Performance management (PM),
../data/rfc/rfc6310.txt: configuration management (CM), Accounting management (AC), and
../data/rfc/rfc6310.txt- Security management (SM). [I.610] describes the functions for the
../data/rfc/rfc6310.txt- operation and maintenance of the physical layer and the ATM layer,
../data/rfc/rfc6310.txt- that is, management at the bit and cell levels. Because of its
../data/rfc/rfc6310.txt- scope, this document will concentrate on ATM fault management
../data/rfc/rfc6310.txt- functions. Fault management functions include the following:
--
../data/rfc/rfc3599.txt-
../data/rfc/rfc3599.txt-
../data/rfc/rfc3599.txt-3588 Calhoun Sep 2003 Diameter Base Protocol
../data/rfc/rfc3599.txt-
../data/rfc/rfc3599.txt-The Diameter base protocol is intended to provide an Authentication,
../data/rfc/rfc3599.txt:Authorization and Accounting (AAA) framework for applications such as
../data/rfc/rfc3599.txt-network access or IP mobility. Diameter is also intended to work in
../data/rfc/rfc3599.txt:both local Authentication, Authorization & Accounting and roaming
../data/rfc/rfc3599.txt-situations. This document specifies the message format, transport,
../data/rfc/rfc3599.txt:error reporting, accounting and security services to be used by all
../data/rfc/rfc3599.txt-Diameter applications. The Diameter base application needs to be
../data/rfc/rfc3599.txt-supported by all Diameter implementations. [STANDARDS TRACK]
../data/rfc/rfc3599.txt-
../data/rfc/rfc3599.txt-
../data/rfc/rfc3599.txt-3587 Hinden Aug 2003 IPv6 Global Unicast Address
--
../data/rfc/rfc3599.txt-efficient for both routers and hosts. This memo defines an Experimental
../data/rfc/rfc3599.txt-Protocol for the Internet community.
../data/rfc/rfc3599.txt-
../data/rfc/rfc3599.txt-
../data/rfc/rfc3599.txt-3539 Aboba Jun 2003 Authentication, Authorization
../data/rfc/rfc3599.txt: and Accounting (AAA) Transport
../data/rfc/rfc3599.txt- Profile
../data/rfc/rfc3599.txt-
../data/rfc/rfc3599.txt-This document discusses transport issues that arise within protocols for
../data/rfc/rfc3599.txt:Authentication, Authorization and Accounting (AAA). It also provides
../data/rfc/rfc3599.txt-recommendations on the use of transport by AAA protocols. This includes
../data/rfc/rfc3599.txt-usage of standards-track RFCs as well as experimental proposals.
../data/rfc/rfc3599.txt-[STANDARDS TRACK]
../data/rfc/rfc3599.txt-
../data/rfc/rfc3599.txt-
--
../data/rfc/rfc3599.txt-3521 Hamer Apr 2003 Framework for Session Set-up
../data/rfc/rfc3599.txt- with Media Authorization
../data/rfc/rfc3599.txt-
../data/rfc/rfc3599.txt-Establishing multimedia streams must take into account requirements for
../data/rfc/rfc3599.txt-end-to-end QoS, authorization of network resource usage and accurate
../data/rfc/rfc3599.txt:accounting for resources used. During session set up, policies may be
../data/rfc/rfc3599.txt-enforced to ensure that the media streams being requested lie within the
../data/rfc/rfc3599.txt-bounds of the service profile established for the requesting host.
../data/rfc/rfc3599.txt-Similarly, when a host requests resources to provide a certain QoS for a
../data/rfc/rfc3599.txt-packet flow, policies may be enforced to ensure that the required
../data/rfc/rfc3599.txt-resources lie within the bounds of the resource profile established for
--
../data/rfc/rfc2834.txt- section 7.1) has an inherent performance limit. In an LIS with n
../data/rfc/rfc2834.txt- ports, the upper bound on the bandwidth that such a service can
../data/rfc/rfc2834.txt- broadcast is:
../data/rfc/rfc2834.txt- (total bandwidth)/(n+1)
../data/rfc/rfc2834.txt-
../data/rfc/rfc2834.txt: since each message must first enter the broadcast server, accounting
../data/rfc/rfc2834.txt- for the additional 1, and then be sent to all n ports. The broadcast
../data/rfc/rfc2834.txt- server could forward the message destined to the port on which it
../data/rfc/rfc2834.txt- runs internally, thus reducing (n+1) to (n) in a first optimization.
../data/rfc/rfc2834.txt-
../data/rfc/rfc2834.txt- This service is adequate for the standard networking protocols such
--
../data/rfc/rfc4241.txt-
../data/rfc/rfc4241.txt-2.2. IP Layer
../data/rfc/rfc4241.txt-
../data/rfc/rfc4241.txt- After IPV6CP negotiation, the CPE initiates a prefix delegation
../data/rfc/rfc4241.txt- request. The PE chooses a global-scope prefix for the CPE with
../data/rfc/rfc4241.txt: information from an Authentication, Authorization, and Accounting
../data/rfc/rfc4241.txt- (AAA) server or local prefix pools, and it delegates the prefix to
../data/rfc/rfc4241.txt- the CPE. Once the prefix is delegated, the prefix is subnetted and
../data/rfc/rfc4241.txt- assigned to the local interfaces of the CPE. The CPE begins sending
../data/rfc/rfc4241.txt-
../data/rfc/rfc4241.txt-
--
../data/rfc/rfc5713.txt- respectively, describe the potential attacks and the different attack
../data/rfc/rfc5713.txt- forms that are liable to take place within ANCP, while Section 7
../data/rfc/rfc5713.txt- applies the described potential attacks to ANCP and its different use
../data/rfc/rfc5713.txt- cases. Security policy negotiation, including authentication and
../data/rfc/rfc5713.txt- authorization to define the per-subscriber policy at the policy/AAA
../data/rfc/rfc5713.txt: (Authentication, Authorization, and Accounting) server, is out of the
../data/rfc/rfc5713.txt- scope of this work. As a high-level summary, the following aspects
../data/rfc/rfc5713.txt- need to be considered:
../data/rfc/rfc5713.txt-
../data/rfc/rfc5713.txt- Message Protection:
../data/rfc/rfc5713.txt-
--
../data/rfc/rfc5713.txt- A NAS provides access to a service (e.g., network access) and
../data/rfc/rfc5713.txt- operates as a client of the AAA protocol. The AAA client is
../data/rfc/rfc5713.txt- responsible for passing authentication information to designated
../data/rfc/rfc5713.txt- AAA servers and then acting on the response that is returned.
../data/rfc/rfc5713.txt-
../data/rfc/rfc5713.txt: Authentication, Authorization, and Accounting (AAA) server:
../data/rfc/rfc5713.txt-
../data/rfc/rfc5713.txt- A AAA server is responsible for authenticating users, authorizing
../data/rfc/rfc5713.txt- access to services, and returning authorization information
../data/rfc/rfc5713.txt- (including configuration parameters) back to the AAA client to
../data/rfc/rfc5713.txt- deliver service to the user. As a consequence, service usage
../data/rfc/rfc5713.txt: accounting might be enabled and information about the user's
../data/rfc/rfc5713.txt- resource usage will be sent to the AAA server.
../data/rfc/rfc5713.txt-
../data/rfc/rfc5713.txt- Access Node (AN):
../data/rfc/rfc5713.txt-
../data/rfc/rfc5713.txt- The AN is a network device, usually located at a service provider
--
../data/rfc/rfc5713.txt-Moustafa, et al. Informational [Page 14]
../data/rfc/rfc5713.txt-
../data/rfc/rfc5713.txt-RFC 5713 ANCP Threats January 2010
../data/rfc/rfc5713.txt-
../data/rfc/rfc5713.txt-
../data/rfc/rfc5713.txt: control, multicast accounting, and spontaneous admission response.
../data/rfc/rfc5713.txt- This section gives a high-level description of the possible attacks
../data/rfc/rfc5713.txt- that can take place in these cases. Attacks that can occur are
../data/rfc/rfc5713.txt- mostly active attacks.
../data/rfc/rfc5713.txt-
../data/rfc/rfc5713.txt- On-path active attacks can be as follows:
--
../data/rfc/rfc5713.txt- in the non-continuity of services.
../data/rfc/rfc5713.txt-
../data/rfc/rfc5713.txt- * Message replay between the AN and the NAS, on the AN or on the
../data/rfc/rfc5713.txt- NAS, leading to a DoS or services fraud.
../data/rfc/rfc5713.txt-
../data/rfc/rfc5713.txt: * Message modification to temper with accounting information, for
../data/rfc/rfc5713.txt- example, in order to avoid service charges or, conversely, in
../data/rfc/rfc5713.txt- order to artificially increase service charges on other users.
../data/rfc/rfc5713.txt-
../data/rfc/rfc5713.txt-
../data/rfc/rfc5713.txt-
--
../data/rfc/rfc1180.txt-
../data/rfc/rfc1180.txt- A B C ----D---- E F G
../data/rfc/rfc1180.txt- | | | | | | | | |
../data/rfc/rfc1180.txt- --o------o------o------o- | -o------o------o------o--
../data/rfc/rfc1180.txt- Ethernet 1 | Ethernet 2
../data/rfc/rfc1180.txt: IP network "development" | IP network "accounting"
../data/rfc/rfc1180.txt- |
../data/rfc/rfc1180.txt- |
../data/rfc/rfc1180.txt- | H I J
../data/rfc/rfc1180.txt- | | | |
../data/rfc/rfc1180.txt- --o-----o------o------o--
--
../data/rfc/rfc1180.txt- IP networks are also given names. If you have 3 IP networks, your
../data/rfc/rfc1180.txt- "networks" file for documenting these names might look something like
../data/rfc/rfc1180.txt- this:
../data/rfc/rfc1180.txt-
../data/rfc/rfc1180.txt- 223.1.2 development
../data/rfc/rfc1180.txt: 223.1.3 accounting
../data/rfc/rfc1180.txt- 223.1.4 factory
../data/rfc/rfc1180.txt-
../data/rfc/rfc1180.txt- The IP network number is in the first column and its name is in the
../data/rfc/rfc1180.txt- second column.
../data/rfc/rfc1180.txt-
--
../data/rfc/rfc1180.txt- | 1 | |1 2 3| | 1 |
../data/rfc/rfc1180.txt- --------- --------- ---------
../data/rfc/rfc1180.txt- | | | | |
../data/rfc/rfc1180.txt- --------o---------------o- | -o----------------o--------
../data/rfc/rfc1180.txt- Ethernet 1 | Ethernet 2
../data/rfc/rfc1180.txt: IP network "Development" | IP network "accounting"
../data/rfc/rfc1180.txt- |
../data/rfc/rfc1180.txt- | --------
../data/rfc/rfc1180.txt- | | iota |
../data/rfc/rfc1180.txt- | | 1 |
../data/rfc/rfc1180.txt- | --------
--
../data/rfc/rfc1180.txt-
../data/rfc/rfc1180.txt- ---------------------------------------------------------------------
../data/rfc/rfc1180.txt- |network direct/indirect flag router interface number|
../data/rfc/rfc1180.txt- ---------------------------------------------------------------------
../data/rfc/rfc1180.txt- |development direct <blank> 1 |
../data/rfc/rfc1180.txt: |accounting indirect devnetrouter 1 |
../data/rfc/rfc1180.txt- |factory indirect devnetrouter 1 |
../data/rfc/rfc1180.txt- ---------------------------------------------------------------------
../data/rfc/rfc1180.txt- TABLE 10. Alpha Route Table
../data/rfc/rfc1180.txt-
../data/rfc/rfc1180.txt- For discussion the table is printed again using numbers instead of
--
../data/rfc/rfc1180.txt- ----------------------------------------------------------------------
../data/rfc/rfc1180.txt- |network direct/indirect flag router interface number|
../data/rfc/rfc1180.txt- ----------------------------------------------------------------------
../data/rfc/rfc1180.txt- |development direct <blank> 1 |
../data/rfc/rfc1180.txt- |factory direct <blank> 3 |
../data/rfc/rfc1180.txt: |accounting direct <blank> 2 |
../data/rfc/rfc1180.txt- ----------------------------------------------------------------------
../data/rfc/rfc1180.txt- TABLE 12. Delta's Route Table
../data/rfc/rfc1180.txt-
../data/rfc/rfc1180.txt- Below is delta's table printed again, without the translation to
../data/rfc/rfc1180.txt- names.
--
../data/rfc/rfc1720.txt- 1673 - Electric Power Research Institute Comments on IPng
../data/rfc/rfc1720.txt-
../data/rfc/rfc1720.txt- This is an information document and does not specify any
../data/rfc/rfc1720.txt- level of standard.
../data/rfc/rfc1720.txt-
../data/rfc/rfc1720.txt: 1672 - Accounting Requirements for IPng
../data/rfc/rfc1720.txt-
../data/rfc/rfc1720.txt- This is an information document and does not specify any
../data/rfc/rfc1720.txt- level of standard.
../data/rfc/rfc1720.txt-
../data/rfc/rfc1720.txt- 1671 - IPng White Paper on Transition and Other Considerations
--
../data/rfc/rfc8711.txt- fundraising, to manage the various contractors that are engaged to
../data/rfc/rfc8711.txt- fulfill the IETF's administrative needs, and to support outreach and
../data/rfc/rfc8711.txt- communications were envisioned.
../data/rfc/rfc8711.txt-
../data/rfc/rfc8711.txt- The IETF has historically benefited from the use of contractors for
../data/rfc/rfc8711.txt: accounting, finance, meeting planning, administrative assistance,
../data/rfc/rfc8711.txt- legal counsel, tools, and web site support, as well as other services
../data/rfc/rfc8711.txt- related to the standards process (e.g., RFC Editor and IANA). Prior
../data/rfc/rfc8711.txt- to making the transition from IASA to IASA 2.0, the IETF budget
../data/rfc/rfc8711.txt- reflected specific support from ISOC for communications and
../data/rfc/rfc8711.txt: fundraising as well as some general support for accounting, finance,
../data/rfc/rfc8711.txt- legal, and other services. The division of responsibilities between
../data/rfc/rfc8711.txt- staff and contractors is at the discretion of the IETF Executive
../data/rfc/rfc8711.txt- Director and their staff.
../data/rfc/rfc8711.txt-
../data/rfc/rfc8711.txt- The IETF has a long history of community involvement in the execution
--
../data/rfc/rfc8711.txt- * Approving any changes to the LLC governance structure.
../data/rfc/rfc8711.txt-
../data/rfc/rfc8711.txt- * Adopting an annual budget and, as necessary, incur any debt.
../data/rfc/rfc8711.txt-
../data/rfc/rfc8711.txt- * Preparing accurate and timely financial statements for ISOC, in
../data/rfc/rfc8711.txt: accordance with generally accepted accounting principles.
../data/rfc/rfc8711.txt-
../data/rfc/rfc8711.txt- * Providing assistance to help facilitate ISOC's tax compliance,
../data/rfc/rfc8711.txt- including but not limited to assistance related to preparing the
../data/rfc/rfc8711.txt- Form 990 and responding to any United States Internal Revenue
../data/rfc/rfc8711.txt- Service (IRS) questions and audits.
--
../data/rfc/rfc2341.txt- 2.3 Virtual dial-up Service - a walk-though 5
../data/rfc/rfc2341.txt- 3.0 Service Model Issues 7
../data/rfc/rfc2341.txt- 3.1 Security 7
../data/rfc/rfc2341.txt- 3.2 Address allocation 8
../data/rfc/rfc2341.txt- 3.3 Authentication 8
../data/rfc/rfc2341.txt: 3.4 Accounting 8
../data/rfc/rfc2341.txt- 4.0 Protocol Definition 9
../data/rfc/rfc2341.txt- 4.1 Encapsulation within L2F 10
../data/rfc/rfc2341.txt- 4.1.1 Encapsulation of PPP within L2F 10
../data/rfc/rfc2341.txt-
../data/rfc/rfc2341.txt-
--
../data/rfc/rfc2341.txt- The address should be assigned by the home site and not the ISP.
../data/rfc/rfc2341.txt-
../data/rfc/rfc2341.txt- + Authorization should be managed by the home site as it would in a
../data/rfc/rfc2341.txt- direct dial-up solution.
../data/rfc/rfc2341.txt-
../data/rfc/rfc2341.txt: + Accounting should be performed both by the ISP (for billing
../data/rfc/rfc2341.txt- purposes) and by the user (for charge-back and auditing).
../data/rfc/rfc2341.txt-
../data/rfc/rfc2341.txt-2.2 Topology
../data/rfc/rfc2341.txt-
../data/rfc/rfc2341.txt- Shown below is a generic Internet with Public switched Telephone
--
../data/rfc/rfc2341.txt- remote user has become simply another dial-up client of the Home
../data/rfc/rfc2341.txt- Gateway access server, client connectivity can now be managed using
../data/rfc/rfc2341.txt- traditional mechanisms with respect to further authorization,
../data/rfc/rfc2341.txt- protocol access, and filtering.
../data/rfc/rfc2341.txt-
../data/rfc/rfc2341.txt: Accounting can be performed at both the NAS as well as the Home
../data/rfc/rfc2341.txt: Gateway. This document illustrates some Accounting techniques which
../data/rfc/rfc2341.txt: are possible using L2F, but the policies surrounding such Accounting
../data/rfc/rfc2341.txt- are outside the scope of this specification.
../data/rfc/rfc2341.txt-
../data/rfc/rfc2341.txt- Because L2F connect notifications for PPP clients contain sufficient
../data/rfc/rfc2341.txt- information for a Home Gateway to authenticate and initialize its LCP
../data/rfc/rfc2341.txt- state machine, it is not required that the remote user be queried a
--
../data/rfc/rfc2341.txt-
../data/rfc/rfc2341.txt-3.0 Service Model Issues
../data/rfc/rfc2341.txt-
../data/rfc/rfc2341.txt- There are several significant differences between the standard
../data/rfc/rfc2341.txt- Internet access service and the Virtual dial-up service with respect
../data/rfc/rfc2341.txt: to authentication, address allocation, authorization and accounting.
../data/rfc/rfc2341.txt- The details of the differences between these services and the
../data/rfc/rfc2341.txt- problems presented by these differences are described below. The
../data/rfc/rfc2341.txt- mechanisms used for Virtual Dial-up service are intended to coexist
../data/rfc/rfc2341.txt- with more traditional mechanisms; it is intended that an ISP's POP
../data/rfc/rfc2341.txt- can simultaneously service ISP clients as well as Virtual dial-up
--
../data/rfc/rfc2341.txt- activities are outside the scope of this specification, but might
../data/rfc/rfc2341.txt- include an additional cycle of LCP authentication, proprietary PPP
../data/rfc/rfc2341.txt- extensions, or textual challenges carried via a TCP/IP telnet
../data/rfc/rfc2341.txt- session.
../data/rfc/rfc2341.txt-
../data/rfc/rfc2341.txt:3.4 Accounting
../data/rfc/rfc2341.txt-
../data/rfc/rfc2341.txt- It is a requirement that both the Access gateway and the Home Gateway
../data/rfc/rfc2341.txt: can provide accounting data and hence both may count packets, octets
../data/rfc/rfc2341.txt- and connection start and stop times.
../data/rfc/rfc2341.txt-
../data/rfc/rfc2341.txt-
../data/rfc/rfc2341.txt-
../data/rfc/rfc2341.txt-
../data/rfc/rfc2341.txt-Valencia, et. al. Historic [Page 8]
../data/rfc/rfc2341.txt-
../data/rfc/rfc2341.txt-RFC 2341 Cisco L2F May 1998
../data/rfc/rfc2341.txt-
../data/rfc/rfc2341.txt-
../data/rfc/rfc2341.txt: Since Virtual dial-up is an access service, accounting of connection
../data/rfc/rfc2341.txt- attempts (in particular, failed connection attempts) is of
../data/rfc/rfc2341.txt- significant interest. The Home Gateway can reject new connections
../data/rfc/rfc2341.txt- based on the authentication information gathered by the ISP, with
../data/rfc/rfc2341.txt- corresponding logging. For cases where the Home Gateway accepts the
../data/rfc/rfc2341.txt- connection and then continues with further authentication, the Home
../data/rfc/rfc2341.txt- Gateway might subsequently disconnect the client. For such
../data/rfc/rfc2341.txt- scenarios, the disconnection indication back to the ISP may also
../data/rfc/rfc2341.txt- include a reason.
../data/rfc/rfc2341.txt-
../data/rfc/rfc2341.txt- Because the Home Gateway can decline a connection based on the
../data/rfc/rfc2341.txt: authentication information collected by the ISP, accounting can
../data/rfc/rfc2341.txt- easily draw a distinction between a series of failed connection
../data/rfc/rfc2341.txt- attempts and a series of brief successful connections. Lacking this
../data/rfc/rfc2341.txt- facility, the Home Gateway must always accept connection requests,
../data/rfc/rfc2341.txt- and would need to exchange a number of PPP packets with the remote
../data/rfc/rfc2341.txt- system.
--
../data/rfc/rfc2341.txt- and received across the Internet.
../data/rfc/rfc2341.txt-
../data/rfc/rfc2341.txt- + Connection management of L2F and MIDs. The tunnel must be
../data/rfc/rfc2341.txt- initiated and terminated, as must MIDs within the tunnel.
../data/rfc/rfc2341.txt- Termination includes diagnostic codes to assist in the diagnosis
../data/rfc/rfc2341.txt: of problems and to support accounting.
../data/rfc/rfc2341.txt-
../data/rfc/rfc2341.txt- While providing these services, the protocol must address the
../data/rfc/rfc2341.txt- following required attributes:
../data/rfc/rfc2341.txt-
../data/rfc/rfc2341.txt- + Low overhead. The protocol must impose a minimal additional
--
../data/rfc/rfc7397.txt- The relationship between the policy enforcement point and the policy
../data/rfc/rfc7397.txt- decision point plays an important role regarding the standardization
../data/rfc/rfc7397.txt- needs and the type of information that needs to be conveyed between
../data/rfc/rfc7397.txt- these two entities.
../data/rfc/rfc7397.txt-
../data/rfc/rfc7397.txt: For example, in an Authentication, Authorization, and Accounting
../data/rfc/rfc7397.txt- (AAA) context, the authorization decision happens at the AAA server
../data/rfc/rfc7397.txt- (after the user requesting access to a network or some application-
../data/rfc/rfc7397.txt- level services had been authenticated). Then, the decision about
../data/rfc/rfc7397.txt- granting access (or rejecting it) is communicated from the AAA server
../data/rfc/rfc7397.txt- to the AAA client at the end of the network access authentication
--
../data/rfc/rfc661.txt-
../data/rfc/rfc661.txt- EXEC (24580,) "The Executive Package"
../data/rfc/rfc661.txt-
../data/rfc/rfc661.txt- This document describes a package that runs in the
../data/rfc/rfc661.txt- setting provided by PCP. It includes procedures and data
../data/rfc/rfc661.txt: stores for user identification, accounting, and usage
../data/rfc/rfc661.txt- information.
../data/rfc/rfc661.txt-
../data/rfc/rfc661.txt- Pathname: [SRI-ARC] <NLS> EXEC.TXT
../data/rfc/rfc661.txt-
../data/rfc/rfc661.txt- FILE (24582,) "The File Package"
--
../data/rfc/rfc5026.txt- +--+
../data/rfc/rfc5026.txt-
../data/rfc/rfc5026.txt- Figure 2 -- Split Scenario (MSA != MSP)
../data/rfc/rfc5026.txt-
../data/rfc/rfc5026.txt- Note that Figure 1 and Figure 2 assume the use of an Authentication,
../data/rfc/rfc5026.txt: Authorization, and Accounting (AAA) protocol to authenticate and
../data/rfc/rfc5026.txt- authorize the Mobile Node for mobility service. However, since the
../data/rfc/rfc5026.txt- Internet Key Exchange Protocol (IKEv2) allows an Extensible
../data/rfc/rfc5026.txt- Authentication Protocol (EAP) client authentication only and the
../data/rfc/rfc5026.txt- server authentication needs to be performed based on certificates or
../data/rfc/rfc5026.txt- public keys, the Mobile Node potentially requires a Certificate
--
../data/rfc/rfc1000.txt-
../data/rfc/rfc1000.txt-
../data/rfc/rfc1000.txt- 223 - Network Information Center Schedule for Network Users
../data/rfc/rfc1000.txt- 185 - NIC Distribution of Manuals and Handbooks
../data/rfc/rfc1000.txt- 154 - Exposition Style
../data/rfc/rfc1000.txt: 136 - Host Accounting and Administrative Procedures
../data/rfc/rfc1000.txt- 118 - Information Required for Each Service Available to the
../data/rfc/rfc1000.txt- Network
../data/rfc/rfc1000.txt- 095 - Distribution of NWG/RFC's Through the NIC
../data/rfc/rfc1000.txt- 016 - MIT
../data/rfc/rfc1000.txt-
--
../data/rfc/rfc1000.txt- 673 Never Issued.
../data/rfc/rfc1000.txt-
../data/rfc/rfc1000.txt- 672 Schantz Dec 74 A Multi-Site Data Collection
../data/rfc/rfc1000.txt- Facility
../data/rfc/rfc1000.txt-
../data/rfc/rfc1000.txt: Applicability of TIP/Tenex protocols beyond TIP accounting.
../data/rfc/rfc1000.txt-
../data/rfc/rfc1000.txt- 671 Schantz Dec 74 A Note on Reconnection Protocol
../data/rfc/rfc1000.txt-
../data/rfc/rfc1000.txt- Experience with implementation in RSEXEC context.
../data/rfc/rfc1000.txt-
--
../data/rfc/rfc1000.txt- Document
../data/rfc/rfc1000.txt-
../data/rfc/rfc1000.txt- Solicitation for review and comment before the Atlantic City NWG
../data/rfc/rfc1000.txt- meetings.
../data/rfc/rfc1000.txt-
../data/rfc/rfc1000.txt: 136 Kahn Apr 71 Host Accounting and Administrative
../data/rfc/rfc1000.txt- Procedures
../data/rfc/rfc1000.txt-
../data/rfc/rfc1000.txt- Discussion of a plan to be formulated and accepted for the
../data/rfc/rfc1000.txt: development of a Host accounting system in the ARPA Network.
../data/rfc/rfc1000.txt-
../data/rfc/rfc1000.txt- 135 Hathaway Apr 71 Response to RFC 110
../data/rfc/rfc1000.txt-
../data/rfc/rfc1000.txt- Comments and proposals of new conventions to replace the ones
../data/rfc/rfc1000.txt- proposed in RFC 110.
--
../data/rfc/rfc3317.txt- Figure 5: Action Usage Example
../data/rfc/rfc3317.txt-
../data/rfc/rfc3317.txt- This example uses the frwkILabelMarker PRC defined in [FR-PIB],
../data/rfc/rfc3317.txt- showing the device internal label being used to indicate the micro
../data/rfc/rfc3317.txt- flow that feeds into the aggregated AF flow. This device internal
../data/rfc/rfc3317.txt: label may be used for flow accounting purposes and/or other data path
../data/rfc/rfc3317.txt- treatments.
../data/rfc/rfc3317.txt-
../data/rfc/rfc3317.txt-5.5. Dropper Examples
../data/rfc/rfc3317.txt-
../data/rfc/rfc3317.txt- The Dropper examples below will continue from the Action example
--
../data/rfc/rfc7575.txt- fundamental to the concept. If a problem can be solved in a
../data/rfc/rfc7575.txt- distributed manner, it should not be centralized.
../data/rfc/rfc7575.txt-
../data/rfc/rfc7575.txt- In certain cases, it is today operationally preferable to keep a
../data/rfc/rfc7575.txt- central repository of information, for example, a user database on an
../data/rfc/rfc7575.txt: Authentication, Authorization, and Accounting (AAA) server. An
../data/rfc/rfc7575.txt- Autonomic Network should be able to use such central systems, in
../data/rfc/rfc7575.txt- order to be deployable. It is possible to distribute such databases
../data/rfc/rfc7575.txt- as well, and such efforts should be at least considered. Depending
../data/rfc/rfc7575.txt- on the case, distribution may not be simple replication but may
../data/rfc/rfc7575.txt- involve more complex interactions and organization.
--
../data/rfc/rfc4851.txt- With these motivational goals defined, further secondary design
../data/rfc/rfc4851.txt- criteria are imposed:
../data/rfc/rfc4851.txt-
../data/rfc/rfc4851.txt- o Flexibility to extend the communications inside the tunnel: with
../data/rfc/rfc4851.txt- the growing complexity in network infrastructures, the need to
../data/rfc/rfc4851.txt: gain authentication, authorization, and accounting is also
../data/rfc/rfc4851.txt- evolving. For instance, there may be instances in which multiple
../data/rfc/rfc4851.txt- existing authentication protocols are required to achieve mutual
../data/rfc/rfc4851.txt- authentication. Similarly, different protected conversations may
../data/rfc/rfc4851.txt- be required to achieve the proper authorization once a peer has
../data/rfc/rfc4851.txt- successfully authenticated.
--
../data/rfc/rfc7119.txt- there is a time gap between the times in the Flow Records, then the
../data/rfc/rfc7119.txt- report may be inaccurate. The IPFIX Mediator is only reporting what
../data/rfc/rfc7119.txt- it knows, on the basis of the information made available to it, and
../data/rfc/rfc7119.txt- there may not have been any data to observe during the gap. Then
../data/rfc/rfc7119.txt- again, if there is an overlap in timestamps, there's the potential of
../data/rfc/rfc7119.txt: double-accounting: different Observation Points may have observed the
../data/rfc/rfc7119.txt- same traffic simultaneously. The specification of the precise rules
../data/rfc/rfc7119.txt- for applying Flow Record timestamps at IPFIX Mediators for all the
../data/rfc/rfc7119.txt- different situations is out of the scope of this document.
../data/rfc/rfc7119.txt-
../data/rfc/rfc7119.txt- Note that [RFC7015] provides additional specifications for handling
--
../data/rfc/rfc3897.txt- OPES System that give the impression that unwanted content
../data/rfc/rfc3897.txt- transformation was performed on the data. This can be achieved by
../data/rfc/rfc3897.txt- inserting wrong entity (such OPES processor) identifiers. A
../data/rfc/rfc3897.txt- compromised trace can affect the overall message integrity structure.
../data/rfc/rfc3897.txt- This can affect entities that use message header information to
../data/rfc/rfc3897.txt: perform services such as accounting, load balancing, or reference-
../data/rfc/rfc3897.txt- based services.
../data/rfc/rfc3897.txt-
../data/rfc/rfc3897.txt-
../data/rfc/rfc3897.txt-
../data/rfc/rfc3897.txt-
--
../data/rfc/rfc3897.txt-RFC 3897 OPES Entities & End Points Communication September 2004
../data/rfc/rfc3897.txt-
../data/rfc/rfc3897.txt-
../data/rfc/rfc3897.txt- Attackers can use the bypass instruction to affect the overall
../data/rfc/rfc3897.txt- integrity of the OPES System. The ability to introduce bypass
../data/rfc/rfc3897.txt: instructions into a data flow may effect the accounting of the OPES
../data/rfc/rfc3897.txt- System. It may also affect the quality of content that is delivered
../data/rfc/rfc3897.txt- to the data consumer applications. Similar threats can arise from
../data/rfc/rfc3897.txt- bad implementations of the bypass facility.
../data/rfc/rfc3897.txt-
../data/rfc/rfc3897.txt- Inconsistent or selective bypass is also a threat. Here, one end can
--
../data/rfc/rfc150.txt-appreciated. Especially of interest are opinions about the usefulness
../data/rfc/rfc150.txt-of the discussion and wether or not there should be more papers
../data/rfc/rfc150.txt-directed at other of the basic questions of computer networking. If
../data/rfc/rfc150.txt-the consensus tends to the affirmative, then others are encouraged to
../data/rfc/rfc150.txt-contribute working papers on the problems of flow control, error
../data/rfc/rfc150.txt:handling, process ownership, accounting, resource control, and the
../data/rfc/rfc150.txt-like.
../data/rfc/rfc150.txt-
../data/rfc/rfc150.txt-
../data/rfc/rfc150.txt-RBK/TX2
../data/rfc/rfc150.txt-
--
../data/rfc/rfc8886.txt-
../data/rfc/rfc8886.txt-4. Operator Role
../data/rfc/rfc8886.txt-
../data/rfc/rfc8886.txt-4.1. Administrative
../data/rfc/rfc8886.txt-
../data/rfc/rfc8886.txt: When purchasing a new device, the accounting department will need to
../data/rfc/rfc8886.txt- get the unique device identifier (e.g., serial number) of the new
../data/rfc/rfc8886.txt- device and communicate it to the operations group.
../data/rfc/rfc8886.txt-
../data/rfc/rfc8886.txt-4.2. Technical
../data/rfc/rfc8886.txt-
--
../data/rfc/rfc3708.txt- segment receipt through duplicate selective acknowledgment (DSACK)
../data/rfc/rfc3708.txt- [RFC2883] and Duplicate TSN notifications, respectively. Using this
../data/rfc/rfc3708.txt- information, a TCP or SCTP sender can generally determine when a
../data/rfc/rfc3708.txt- retransmission was sent in error. This document presents two methods
../data/rfc/rfc3708.txt- for using duplicate notifications. The first method is simple and
../data/rfc/rfc3708.txt: can be used for accounting applications. The second method is a
../data/rfc/rfc3708.txt- conservative algorithm to disambiguate unnecessary retransmissions
../data/rfc/rfc3708.txt- from loss events for the purpose of undoing unnecessary congestion
../data/rfc/rfc3708.txt- control changes.
../data/rfc/rfc3708.txt-
../data/rfc/rfc3708.txt-
--
../data/rfc/rfc8658.txt- period. DHCPv6 options have been defined to configure clients for
../data/rfc/rfc8658.txt- Lightweight 4over6, Mapping of Address and Port with Encapsulation
../data/rfc/rfc8658.txt- (MAP-E), Mapping of Address and Port using Translation (MAP-T)
../data/rfc/rfc8658.txt- unicast softwire mechanisms, and multicast softwires. However, in
../data/rfc/rfc8658.txt- many networks, configuration information is stored in an
../data/rfc/rfc8658.txt: Authentication, Authorization, and Accounting (AAA) server, which
../data/rfc/rfc8658.txt- utilizes the Remote Authentication Dial In User Service (RADIUS)
../data/rfc/rfc8658.txt- protocol to provide centralized management for users. When a new
../data/rfc/rfc8658.txt- transition mechanism is developed, new RADIUS attributes need to be
../data/rfc/rfc8658.txt- defined correspondingly.
../data/rfc/rfc8658.txt-
--
../data/rfc/rfc8658.txt- multicast services to IPv4 clients over an IPv6 multicast network.
../data/rfc/rfc8658.txt- For each of these mechanisms, DHCPv6 options have been specified for
../data/rfc/rfc8658.txt- client configuration.
../data/rfc/rfc8658.txt-
../data/rfc/rfc8658.txt- In many networks, user configuration information is stored in an
../data/rfc/rfc8658.txt: Authentication, Authorization, and Accounting (AAA) server. AAA
../data/rfc/rfc8658.txt- servers generally communicate using the Remote Authentication Dial In
../data/rfc/rfc8658.txt- User Service (RADIUS) [RFC2865] protocol. In a fixed broadband
../data/rfc/rfc8658.txt- network, a Broadband Network Gateway (BNG) acts as the access gateway
../data/rfc/rfc8658.txt- for users. That is, the BNG acts as both a AAA client to the AAA
../data/rfc/rfc8658.txt- server and a DHCPv6 server for DHCPv6 messages sent by clients.
--
../data/rfc/rfc8658.txt-
../data/rfc/rfc8658.txt- * The Softwire46-Configuration Attribute MAY appear in a CoA-Request
../data/rfc/rfc8658.txt- packet.
../data/rfc/rfc8658.txt-
../data/rfc/rfc8658.txt- * The Softwire46-Configuration Attribute MAY appear in an
../data/rfc/rfc8658.txt: Accounting-Request packet.
../data/rfc/rfc8658.txt-
../data/rfc/rfc8658.txt- * The Softwire46-Configuration Attribute MUST NOT appear in any
../data/rfc/rfc8658.txt- other RADIUS packet.
../data/rfc/rfc8658.txt-
../data/rfc/rfc8658.txt- The Softwire46-Configuration Attribute is structured as follows:
--
../data/rfc/rfc8658.txt- packet. It MAY also appear in an Access-Request packet.
../data/rfc/rfc8658.txt-
../data/rfc/rfc8658.txt- The Softwire46-Priority Attribute MAY appear in a CoA-Request
../data/rfc/rfc8658.txt- packet.
../data/rfc/rfc8658.txt-
../data/rfc/rfc8658.txt: The Softwire46-Priority Attribute MAY appear in an Accounting-
../data/rfc/rfc8658.txt- Request packet.
../data/rfc/rfc8658.txt-
../data/rfc/rfc8658.txt- The Softwire46-Priority Attribute MUST NOT appear in any other
../data/rfc/rfc8658.txt- RADIUS packet.
../data/rfc/rfc8658.txt-
--
../data/rfc/rfc8658.txt- Softwire46-Multicast, these prefixes may be inserted in the
../data/rfc/rfc8658.txt- attribute. The RADIUS server MAY ignore the hint sent by the BNG,
../data/rfc/rfc8658.txt- and it MAY assign a different Softwire46-Multicast Attribute.
../data/rfc/rfc8658.txt-
../data/rfc/rfc8658.txt- * The Softwire46-Multicast Attribute MAY appear in an Access-
../data/rfc/rfc8658.txt: Request, Access-Accept, CoA-Request, and Accounting-Request
../data/rfc/rfc8658.txt- packet.
../data/rfc/rfc8658.txt-
../data/rfc/rfc8658.txt- * The Softwire46-Multicast Attribute MUST NOT appear in any other
../data/rfc/rfc8658.txt- RADIUS packet.
../data/rfc/rfc8658.txt-
--
../data/rfc/rfc8658.txt- (lwAFTR)/BR. This can be achieved in two ways: static
../data/rfc/rfc8658.txt- preconfiguration of the bindings on both the AAA server and lwAFTR
../data/rfc/rfc8658.txt- or on demand, whereby the AAA server updates the lwAFTR with the
../data/rfc/rfc8658.txt- CE's binding state as it is created or deleted.
../data/rfc/rfc8658.txt-
../data/rfc/rfc8658.txt: In some deployments, the DHCP server may use the Accounting-Request
../data/rfc/rfc8658.txt- to report the softwire configuration returned to a requesting host to
../data/rfc/rfc8658.txt- a AAA server. It is the responsibility of the DHCP server to ensure
../data/rfc/rfc8658.txt- the consistency of the configuration provided to the requesting
../data/rfc/rfc8658.txt- hosts. Reported data to a AAA server may be required for various
../data/rfc/rfc8658.txt- operational purposes (e.g., regulatory).
--
../data/rfc/rfc3576.txt-
../data/rfc/rfc3576.txt- The packet format consists of the fields: Code, Identifier, Length,
../data/rfc/rfc3576.txt- Authenticator, and Attributes in Type:Length:Value (TLV) format. All
../data/rfc/rfc3576.txt- fields hold the same meaning as those described in RADIUS [RFC2865].
../data/rfc/rfc3576.txt- The Authenticator field MUST be calculated in the same way as is
../data/rfc/rfc3576.txt: specified for an Accounting-Request in [RFC2866].
../data/rfc/rfc3576.txt-
../data/rfc/rfc3576.txt- 0 1 2 3
../data/rfc/rfc3576.txt- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
../data/rfc/rfc3576.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
../data/rfc/rfc3576.txt- | Code | Identifier | Length |
--
../data/rfc/rfc3576.txt-
../data/rfc/rfc3576.txt- Request Authenticator
../data/rfc/rfc3576.txt-
../data/rfc/rfc3576.txt- In Request packets, the Authenticator value is a 16 octet MD5
../data/rfc/rfc3576.txt- [RFC1321] checksum, called the Request Authenticator. The Request
../data/rfc/rfc3576.txt: Authenticator is calculated the same way as for an Accounting-
../data/rfc/rfc3576.txt- Request, specified in [RFC2866].
../data/rfc/rfc3576.txt-
../data/rfc/rfc3576.txt- Note that the Request Authenticator of a Disconnect or CoA-Request
../data/rfc/rfc3576.txt- cannot be done the same way as the Request Authenticator of a
../data/rfc/rfc3576.txt- RADIUS Access-Request, because there is no User-Password Attribute
--
../data/rfc/rfc3576.txt- here a Disconnect-NAK MUST be sent.
../data/rfc/rfc3576.txt-
../data/rfc/rfc3576.txt- Since within this specification attributes may be used for
../data/rfc/rfc3576.txt- identification, authorization or other purposes, even if a NAS
../data/rfc/rfc3576.txt- implements an attribute for use with RADIUS authentication and
../data/rfc/rfc3576.txt: accounting, it may not support inclusion of that attribute within
../data/rfc/rfc3576.txt- Disconnect-Request or CoA-Request messages, given the difference
../data/rfc/rfc3576.txt- in attribute semantics. This is true even for attributes
../data/rfc/rfc3576.txt- specified within [RFC2865], [RFC2868], [RFC2869] or [RFC3162] as
../data/rfc/rfc3576.txt- allowable within Access-Accept messages.
../data/rfc/rfc3576.txt-
--
../data/rfc/rfc3576.txt- attribute value is to remain unchanged. Attributes included in a
../data/rfc/rfc3576.txt- CoA-Request replace all existing value(s) of the same attribute(s).
../data/rfc/rfc3576.txt-
../data/rfc/rfc3576.txt- [Note 4] When included within a successful Disconnect-Request (where
../data/rfc/rfc3576.txt- a Disconnect-ACK is subsequently sent), the Class Attribute SHOULD be
../data/rfc/rfc3576.txt: sent unmodified by the client to the accounting server in the
../data/rfc/rfc3576.txt: Accounting Stop packet. If the Disconnect-Request is unsuccessful,
../data/rfc/rfc3576.txt- then the Class Attribute is not processed.
../data/rfc/rfc3576.txt-
../data/rfc/rfc3576.txt- [Note 5] When included within a CoA-Request, these attributes
../data/rfc/rfc3576.txt- represent an authorization change request. Where tunnel attribute(s)
../data/rfc/rfc3576.txt- are sent within a successful CoA-Request, all existing tunnel
--
../data/rfc/rfc3576.txt- used to provide per-packet confidentiality, authentication, integrity
../data/rfc/rfc3576.txt- and replay protection. IKE SHOULD be used for key management.
../data/rfc/rfc3576.txt-
../data/rfc/rfc3576.txt- Within RADIUS [RFC2865], a shared secret is used for hiding
../data/rfc/rfc3576.txt- Attributes such as User-Password, as well as used in computation of
../data/rfc/rfc3576.txt: the Response Authenticator. In RADIUS accounting [RFC2866], the
../data/rfc/rfc3576.txt- shared secret is used in computation of both the Request
../data/rfc/rfc3576.txt- Authenticator and the Response Authenticator.
../data/rfc/rfc3576.txt-
../data/rfc/rfc3576.txt- Since in RADIUS a shared secret is used to provide confidentiality as
../data/rfc/rfc3576.txt- well as integrity protection and authentication, only use of IPsec
--
../data/rfc/rfc3576.txt-
../data/rfc/rfc3576.txt- [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
../data/rfc/rfc3576.txt- "Remote Authentication Dial In User Service (RADIUS)",
../data/rfc/rfc3576.txt- RFC 2865, June 2000.
../data/rfc/rfc3576.txt-
../data/rfc/rfc3576.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc3576.txt-
../data/rfc/rfc3576.txt- [RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS
../data/rfc/rfc3576.txt- Extensions", RFC 2869, June 2000.
../data/rfc/rfc3576.txt-
../data/rfc/rfc3576.txt- [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6",
--
../data/rfc/rfc3576.txt-
../data/rfc/rfc3576.txt- [RFC2983] Black, D. "Differentiated Services and Tunnels", RFC
../data/rfc/rfc3576.txt- 2983, October 2000.
../data/rfc/rfc3576.txt-
../data/rfc/rfc3576.txt- [AAATransport] Aboba, B. and J. Wood, "Authentication, Authorization
../data/rfc/rfc3576.txt: and Accounting (AAA) Transport Profile", RFC 3539,
../data/rfc/rfc3576.txt- June 2003.
../data/rfc/rfc3576.txt-
../data/rfc/rfc3576.txt- [Diameter] Calhoun, P., et al., "Diameter Base Protocol", Work in
../data/rfc/rfc3576.txt- Progress.
../data/rfc/rfc3576.txt-
--
../data/rfc/rfc4849.txt- unsupported attribute. It is RECOMMENDED that an Error-Cause
../data/rfc/rfc4849.txt- attribute with value set to "Unsupported Attribute" (401) be included
../data/rfc/rfc4849.txt- in the CoA-NAK. As noted in [RFC3576], authorization changes are
../data/rfc/rfc4849.txt- atomic so that this situation does not result in session termination,
../data/rfc/rfc4849.txt- and the pre-existing configuration remains unchanged. As a result,
../data/rfc/rfc4849.txt: no accounting packets should be generated because of the CoA-Request.
../data/rfc/rfc4849.txt-
../data/rfc/rfc4849.txt-2. NAS-Filter-Rule Attribute
../data/rfc/rfc4849.txt-
../data/rfc/rfc4849.txt- Description
../data/rfc/rfc4849.txt-
../data/rfc/rfc4849.txt- This attribute indicates filter rules to be applied for this user.
../data/rfc/rfc4849.txt- Zero or more NAS-Filter-Rule attributes MAY be sent in Access-Accept,
../data/rfc/rfc4849.txt: CoA-Request, or Accounting-Request packets.
../data/rfc/rfc4849.txt-
../data/rfc/rfc4849.txt- The NAS-Filter-Rule attribute is not intended to be used concurrently
../data/rfc/rfc4849.txt- with any other filter rule attribute, including Filter-Id (11) and
../data/rfc/rfc4849.txt- NAS-Traffic-Rule [Traffic] attributes. NAS-Filter-Rule and NAS-
../data/rfc/rfc4849.txt- Traffic-Rule attributes MUST NOT appear in the same RADIUS packet.
--
../data/rfc/rfc4849.txt- range.
../data/rfc/rfc4849.txt-
../data/rfc/rfc4849.txt-6. Security Considerations
../data/rfc/rfc4849.txt-
../data/rfc/rfc4849.txt- This specification describes the use of RADIUS for purposes of
../data/rfc/rfc4849.txt: authentication, authorization and accounting. Threats and security
../data/rfc/rfc4849.txt- issues for this application are described in [RFC3579] and [RFC3580];
../data/rfc/rfc4849.txt- security issues encountered in roaming are described in [RFC2607].
../data/rfc/rfc4849.txt-
../data/rfc/rfc4849.txt- This document specifies a new attribute that can be included in
../data/rfc/rfc4849.txt- existing RADIUS packets, which are protected as described in
--
../data/rfc/rfc4849.txt- in transit. They do not prevent an authorized RADIUS/Diameter server
../data/rfc/rfc4849.txt- or proxy from modifying, inserting, or removing attributes with
../data/rfc/rfc4849.txt- malicious intent. Filter attributes modified or removed by a
../data/rfc/rfc4849.txt- RADIUS/Diameter proxy may enable a user to obtain network access
../data/rfc/rfc4849.txt- without the appropriate filters; if the proxy were also to modify
../data/rfc/rfc4849.txt: accounting packets, then the modification would not be reflected in
../data/rfc/rfc4849.txt: the accounting server logs.
../data/rfc/rfc4849.txt-
../data/rfc/rfc4849.txt- Since the RADIUS protocol currently does not support capability
../data/rfc/rfc4849.txt- negotiation, a RADIUS server cannot automatically discover whether a
../data/rfc/rfc4849.txt- NAS supports the NAS-Filter-Rule attribute. A legacy NAS not
../data/rfc/rfc4849.txt- compliant with this specification may silently discard the NAS-
--
../data/rfc/rfc4378.txt-
../data/rfc/rfc4378.txt- This document is a framework for how data plane protocols can be
../data/rfc/rfc4378.txt- applied to operations and maintenance procedures for Multi-Protocol
../data/rfc/rfc4378.txt- Label Switching (MPLS). The document is structured to outline how
../data/rfc/rfc4378.txt- Operations and Management (OAM) functionality can be used to assist
../data/rfc/rfc4378.txt: in fault, configuration, accounting, performance, and security
../data/rfc/rfc4378.txt- management, commonly known by the acronym FCAPS.
../data/rfc/rfc4378.txt-
../data/rfc/rfc4378.txt-Table of Contents
../data/rfc/rfc4378.txt-
../data/rfc/rfc4378.txt- 1. Introduction ....................................................2
--
../data/rfc/rfc4378.txt- 3. Fault Management ................................................2
../data/rfc/rfc4378.txt- 3.1. Fault Detection ............................................2
../data/rfc/rfc4378.txt- 3.2. Diagnosis ..................................................6
../data/rfc/rfc4378.txt- 3.3. Availability ...............................................7
../data/rfc/rfc4378.txt- 4. Configuration Management ........................................7
../data/rfc/rfc4378.txt: 5. Accounting ......................................................7
../data/rfc/rfc4378.txt- 6. Performance Management ..........................................7
../data/rfc/rfc4378.txt- 7. Security Management .............................................8
../data/rfc/rfc4378.txt- 8. Security Considerations .........................................9
../data/rfc/rfc4378.txt- 9. Acknowledgements ................................................9
../data/rfc/rfc4378.txt- 10. Normative References ...........................................9
--
../data/rfc/rfc4378.txt-1. Introduction
../data/rfc/rfc4378.txt-
../data/rfc/rfc4378.txt- This memo outlines in broader terms how data plane protocols can
../data/rfc/rfc4378.txt- assist in meeting the Operations and Management (OAM) requirements
../data/rfc/rfc4378.txt- outlined in [RFC4377] and [Y1710] and can apply to the management
../data/rfc/rfc4378.txt: functions of fault, configuration, accounting, performance, and
../data/rfc/rfc4378.txt- security (commonly known as FCAPS) for MPLS networks, as defined in
../data/rfc/rfc4378.txt- [RFC3031]. The approach of the document is to outline functionality,
../data/rfc/rfc4378.txt- the potential mechanisms to provide the function, and the required
../data/rfc/rfc4378.txt- applicability of data plane OAM functions. Included in the
../data/rfc/rfc4378.txt- discussion are security issues specific to use of tools within a
--
../data/rfc/rfc4378.txt- path function is synchronized with the control plane. As part of the
../data/rfc/rfc4378.txt- payload, the probe would carry relevant control plane information
../data/rfc/rfc4378.txt- that the receiver would be able to compare with the local-control
../data/rfc/rfc4378.txt- plane configuration.
../data/rfc/rfc4378.txt-
../data/rfc/rfc4378.txt:5. Accounting
../data/rfc/rfc4378.txt-
../data/rfc/rfc4378.txt: The requirements for accounting in MPLS networks, as specified in
../data/rfc/rfc4378.txt- [RFC4377], do not place any requirements on data plane OAM.
../data/rfc/rfc4378.txt-
../data/rfc/rfc4378.txt-6. Performance Management
../data/rfc/rfc4378.txt-
../data/rfc/rfc4378.txt- Performance management permits the information transfer
--
../data/rfc/rfc1077.txt- 2.5. Network Management and Routing
../data/rfc/rfc1077.txt-
../data/rfc/rfc1077.txt-
../data/rfc/rfc1077.txt- The objective of network management is to ensure that the network
../data/rfc/rfc1077.txt- functions smoothly and efficiently, and consists of the following:
../data/rfc/rfc1077.txt: accounting, security, performance monitoring, fault isolation and
../data/rfc/rfc1077.txt- configuration control.
../data/rfc/rfc1077.txt-
../data/rfc/rfc1077.txt: Accounting ensures that users are properly billed for the services
../data/rfc/rfc1077.txt: that the network provides. Accounting enforces a tariff; a tariff
../data/rfc/rfc1077.txt- expresses a usage policy. The network need only keep track of those
../data/rfc/rfc1077.txt- items addressed by the tariff, such as allocated bandwidth, number of
../data/rfc/rfc1077.txt: packets sent, number of ports used, etc. Another type of accounting
../data/rfc/rfc1077.txt- may need to be supported by the network to support resource sharing,
../data/rfc/rfc1077.txt: namely accounting analogous to telephone "900" numbers. This
../data/rfc/rfc1077.txt: accounting performed by the network on behalf of resource providers
../data/rfc/rfc1077.txt- and consumers is a pragmatic solution to the problem of getting the
../data/rfc/rfc1077.txt- users and consumers into a financial relationship with each other
../data/rfc/rfc1077.txt- which has stymied previous attempts to achieve widespread use of
../data/rfc/rfc1077.txt- specialized resources.
../data/rfc/rfc1077.txt-
--
../data/rfc/rfc1077.txt-
../data/rfc/rfc1077.txt- One approach is to use a general three-level structure, corresponding
../data/rfc/rfc1077.txt- to interadministrational, intraadministrational, and cluster
../data/rfc/rfc1077.txt- networks. The first level interconnects communication facilities of
../data/rfc/rfc1077.txt- truly separate administrations where there is significant separation
../data/rfc/rfc1077.txt: of security, accounting, and goals. The second level interconnects
../data/rfc/rfc1077.txt- subadministrations which exist for management convenience in large
../data/rfc/rfc1077.txt- organizations. For example, a research group within a university may
../data/rfc/rfc1077.txt- function as a subadministration. The cluster level consists of
../data/rfc/rfc1077.txt- networks configured to provides maximal performance among hosts which
../data/rfc/rfc1077.txt- are in frequent communication, such as a set of diskless workstations
--
../data/rfc/rfc1077.txt- and management. Internetworking must support cohesion within an
../data/rfc/rfc1077.txt- administration and a healthy separation between administrations. To
../data/rfc/rfc1077.txt- illustrate by analogy, the American and Soviet embassies in Mexico
../data/rfc/rfc1077.txt- City are geographically closer to each other than to their respective
../data/rfc/rfc1077.txt- home countries but further in administrational distance, including
../data/rfc/rfc1077.txt: security, accounting, etc. The emerging revolution in WANs makes
../data/rfc/rfc1077.txt- this issue that much more critical. The amount of communication to
../data/rfc/rfc1077.txt- exchange the state of systems is bound to increase enormously. The
../data/rfc/rfc1077.txt- potential cost of failures and security violations is frightening.
../data/rfc/rfc1077.txt-
../data/rfc/rfc1077.txt- A promising approach appears to be high-level gateways that guard
../data/rfc/rfc1077.txt- between administrations and require negotiations to set up access
../data/rfc/rfc1077.txt- paths between administrations. These paths are set up, and labeled
../data/rfc/rfc1077.txt: with agreements on authorization, security, accounting, and possible
../data/rfc/rfc1077.txt- resource limits. These administrative virtual circuits provide
../data/rfc/rfc1077.txt- transparency to the physical and geographical interconnection, but
../data/rfc/rfc1077.txt- need not support more than datagram packet delivery. One view is
../data/rfc/rfc1077.txt- that of communication contracts with high-level gateways acting as
../data/rfc/rfc1077.txt-
--
../data/rfc/rfc1077.txt-
../data/rfc/rfc1077.txt-
../data/rfc/rfc1077.txt- Networks of today generally select routes based on minimizing some
../data/rfc/rfc1077.txt- measure such as delay. However, in the real world, route selection
../data/rfc/rfc1077.txt- will commonly be constrained at the global level by policy issues,
../data/rfc/rfc1077.txt: such as access rights to resources and accounting and billing for
../data/rfc/rfc1077.txt- usage.
../data/rfc/rfc1077.txt-
../data/rfc/rfc1077.txt- It is difficult for connectionless protocols such as Internet to deal
../data/rfc/rfc1077.txt- with policy controls, because a lack of state in the gateway implies
../data/rfc/rfc1077.txt- that a separate policy decision must be made for each packet in
--
../data/rfc/rfc1077.txt- one point only, and then attached to the packet. Both of these
../data/rfc/rfc1077.txt- approaches have problems. A two-pronged research program is needed,
../data/rfc/rfc1077.txt- in which mechanisms are proposed, and at the same time the needed
../data/rfc/rfc1077.txt- policies are defined.
../data/rfc/rfc1077.txt-
../data/rfc/rfc1077.txt: The same trade-off can be seen for accounting and billing. A single
../data/rfc/rfc1077.txt: accounting metric, such as "bytes times distance", could be proposed.
../data/rfc/rfc1077.txt- This might be somewhat simple to implement, but would not permit the
../data/rfc/rfc1077.txt- definition of individual billing policies, as is now done in the
../data/rfc/rfc1077.txt- parts of the telephone system. The current connectionless transport
../data/rfc/rfc1077.txt- architectures such as TCP/IP or the connectionless ISO configuration
../data/rfc/rfc1077.txt: using TP4 do not have good tools for accounting for traffic, or for
../data/rfc/rfc1077.txt- restricting traffic from certain resources. Building these tools is
../data/rfc/rfc1077.txt: difficult in a connectionless environment, because an accounting or
../data/rfc/rfc1077.txt- control facility must deal with each packet in isolation, which
../data/rfc/rfc1077.txt- implies a significant processing burden as part of packet forwarding.
../data/rfc/rfc1077.txt- This burden is an increasing problem as switches are expected to
../data/rfc/rfc1077.txt- operate faster.
../data/rfc/rfc1077.txt-
../data/rfc/rfc1077.txt- The lack of these tools is proving a significant problem for network
../data/rfc/rfc1077.txt: design. Not only are accounting and control needed to support
../data/rfc/rfc1077.txt- management requirements, they are needed as a building block to
../data/rfc/rfc1077.txt- support enforcement of such things as multiple qualities of service,
../data/rfc/rfc1077.txt- as discussed above.
../data/rfc/rfc1077.txt-
../data/rfc/rfc1077.txt: Network accounting is generally considered to be simply a step that
../data/rfc/rfc1077.txt- leads to billing, and thus is often evaluated in terms of how simple
../data/rfc/rfc1077.txt: or difficult it will be to implement. Yet an accounting and billing
../data/rfc/rfc1077.txt- procedure is a mechanism for implementing a policy considered to be
../data/rfc/rfc1077.txt: desirable for reasons beyond the scope of accounting per se. For
../data/rfc/rfc1077.txt- example, a policy might be established either to encourage or
../data/rfc/rfc1077.txt- discourage network use, while fully recovering operational cost. A
../data/rfc/rfc1077.txt- policy of encouraging use could be implemented by a relatively high
../data/rfc/rfc1077.txt- monthly attachment charge and a relatively low per-packet charge. A
../data/rfc/rfc1077.txt- policy of discouraging use could be implemented by a low monthly
--
../data/rfc/rfc1077.txt- 5. Access charges (e.g., per port, or port * [bandwidth of
../data/rfc/rfc1077.txt- port]).
../data/rfc/rfc1077.txt-
../data/rfc/rfc1077.txt- 6. Distance (e.g., circuit-miles, airline miles, number of hops).
../data/rfc/rfc1077.txt-
../data/rfc/rfc1077.txt: Generally, an accounting procedure can be developed to support
../data/rfc/rfc1077.txt- voluntary user cooperation with almost any single policy objective.
../data/rfc/rfc1077.txt- Difficulties most often arise when there are multiple competing
../data/rfc/rfc1077.txt- policy objectives, or when there is no clear policy at all.
../data/rfc/rfc1077.txt-
../data/rfc/rfc1077.txt: Another aspect of accounting and billing procedures which must be
../data/rfc/rfc1077.txt- carefully considered is the cost of accumulating and processing the
../data/rfc/rfc1077.txt- data on which billing is based. Of particular concern is collection
../data/rfc/rfc1077.txt- of detailed data on a per-packet basis. As network circuit data
../data/rfc/rfc1077.txt- rates increase, the number of instructions which must be executed on
../data/rfc/rfc1077.txt- a per-packet basis can become the limiting factor in system
../data/rfc/rfc1077.txt: throughput. Thus, it may be appropriate to prefer accounting and
../data/rfc/rfc1077.txt- billing policies and procedures which minimize the difficulty of
../data/rfc/rfc1077.txt- collecting data, even if this approach requires a compromise of other
../data/rfc/rfc1077.txt- objectives. Similarly, node memory required for data collection and
../data/rfc/rfc1077.txt- any network bandwidth required for transmission of the data to
../data/rfc/rfc1077.txt- administrative headquarters are factors which must be traded off
--
../data/rfc/rfc187.txt-restart for the network.
../data/rfc/rfc187.txt-
../data/rfc/rfc187.txt-Files routed specifically for execution require a third status message
../data/rfc/rfc187.txt-from the receiving user system. The system must indicate when and how
../data/rfc/rfc187.txt-the job completed execution. This status message will also contain the
../data/rfc/rfc187.txt:appropriate accounting information to allow dynamic updating of network
../data/rfc/rfc187.txt:user and system accounting information. It is not clear at this time
../data/rfc/rfc187.txt-what should be accounted for in the network, but it is an area of prime
../data/rfc/rfc187.txt-concern to operational networks.
../data/rfc/rfc187.txt-
../data/rfc/rfc187.txt-An error in the second logic level can occur during the file
../data/rfc/rfc187.txt-transmission. There may be an error moving files from devices into the
--
../data/rfc/rfc6408.txt- +------------------+----------------------------+
../data/rfc/rfc6408.txt- | Tag | Diameter Application |
../data/rfc/rfc6408.txt- +------------------+----------------------------+
../data/rfc/rfc6408.txt- | aaa+ap1 | NASREQ [RFC3588] |
../data/rfc/rfc6408.txt- | aaa+ap2 | Mobile IPv4 [RFC4004] |
../data/rfc/rfc6408.txt: | aaa+ap3 | Base Accounting [RFC3588] |
../data/rfc/rfc6408.txt- | aaa+ap4 | Credit Control [RFC4006] |
../data/rfc/rfc6408.txt- | aaa+ap5 | EAP [RFC4072] |
../data/rfc/rfc6408.txt- | aaa+ap6 | SIP [RFC4740] |
../data/rfc/rfc6408.txt- | aaa+ap7 | Mobile IPv6 IKE [RFC5778] |
../data/rfc/rfc6408.txt- | aaa+ap8 | Mobile IPv6 Auth [RFC5778] |
--
../data/rfc/rfc6408.txt- | Tag | Diameter Application |
../data/rfc/rfc6408.txt- +----------------+--------------------------------------------------+
../data/rfc/rfc6408.txt- | aaa+ap16777281 | WiMAX Network Access Authentication and |
../data/rfc/rfc6408.txt- | | Authorization Diameter Application (WNAAADA) |
../data/rfc/rfc6408.txt- | | [WiMAX-BASE] |
../data/rfc/rfc6408.txt: | aaa+ap16777282 | WiMAX Network Accounting Diameter Application |
../data/rfc/rfc6408.txt- | | (WNADA) [WiMAX-BASE] |
../data/rfc/rfc6408.txt- | aaa+ap16777283 | WiMAX MIP4 Diameter Application (WM4DA) |
../data/rfc/rfc6408.txt- | | [WiMAX-BASE] |
../data/rfc/rfc6408.txt- | aaa+ap16777284 | WiMAX MIP6 Diameter Application (WM6DA) |
../data/rfc/rfc6408.txt- | | [WiMAX-BASE] |
--
../data/rfc/rfc6930.txt- IPv4 and IPv6 connectivity services simultaneously during the
../data/rfc/rfc6930.txt- IPv4/IPv6 coexistence period. The Dynamic Host Configuration
../data/rfc/rfc6930.txt- Protocol (DHCP) 6rd option has been defined to configure the 6rd
../data/rfc/rfc6930.txt- Customer Edge (CE). However, in many networks, the configuration
../data/rfc/rfc6930.txt- information may be stored in the Authentication Authorization and
../data/rfc/rfc6930.txt: Accounting (AAA) servers, while user configuration is mainly acquired
../data/rfc/rfc6930.txt- from a Broadband Network Gateway (BNG) through the DHCP protocol.
../data/rfc/rfc6930.txt- This document defines a Remote Authentication Dial-In User Service
../data/rfc/rfc6930.txt- (RADIUS) attribute that carries 6rd configuration information from
../data/rfc/rfc6930.txt- the AAA server to BNGs.
../data/rfc/rfc6930.txt-
--
../data/rfc/rfc6930.txt- the 6rd Customer Edge (CE) uses the DHCP 6rd option [RFC5969] to
../data/rfc/rfc6930.txt- discover a 6rd Border Relay and to configure an IPv6 prefix and
../data/rfc/rfc6930.txt- address.
../data/rfc/rfc6930.txt-
../data/rfc/rfc6930.txt- In many networks, user-configuration information is managed by
../data/rfc/rfc6930.txt: Authentication, Authorization, and Accounting (AAA) servers. The
../data/rfc/rfc6930.txt- Remote Authentication Dial-In User Service (RADIUS) protocol
../data/rfc/rfc6930.txt- [RFC2865] is usually used by AAA servers to communicate with network
../data/rfc/rfc6930.txt- elements. In a fixed-line broadband network, the Broadband Network
../data/rfc/rfc6930.txt- Gateways (BNGs) act as the access gateway for users. The BNGs are
../data/rfc/rfc6930.txt- assumed to embed a DHCP server function that allows them to handle
--
../data/rfc/rfc6930.txt-
../data/rfc/rfc6930.txt- The following table adds to the one in [RFC2865], Section 5.44,
../data/rfc/rfc6930.txt- providing a guide to the quantity of IPv6-6rd-Configuration
../data/rfc/rfc6930.txt- attributes that may be found in each kind of packet.
../data/rfc/rfc6930.txt-
../data/rfc/rfc6930.txt: Request Accept Reject Challenge Accounting # Attribute
../data/rfc/rfc6930.txt- Request
../data/rfc/rfc6930.txt- 0-1 0-1 0 0 0-1 173 IPv6-6rd-
../data/rfc/rfc6930.txt- Configuration
../data/rfc/rfc6930.txt- 0-1 0-1 0 0 0-1 1 User-Name
../data/rfc/rfc6930.txt- 0-1 0 0 0 0-1 2 User-Password
--
../data/rfc/rfc2990.txt- 3.4 QoS Routing and Resource Management ................ 10
../data/rfc/rfc2990.txt- 3.5 TCP and QoS ........................................ 11
../data/rfc/rfc2990.txt- 3.6 Per-Flow States and Per-Packet classifiers ......... 13
../data/rfc/rfc2990.txt- 3.7 The Service Set .................................... 14
../data/rfc/rfc2990.txt- 3.8 Measuring Service Delivery ......................... 14
../data/rfc/rfc2990.txt: 3.9 QoS Accounting ..................................... 15
../data/rfc/rfc2990.txt- 3.10 QoS Deployment Diversity .......................... 16
../data/rfc/rfc2990.txt- 3.11 QoS Inter-Domain signaling ........................ 17
../data/rfc/rfc2990.txt-
../data/rfc/rfc2990.txt-
../data/rfc/rfc2990.txt-
--
../data/rfc/rfc2990.txt- justified in terms of superior application performance.
../data/rfc/rfc2990.txt-
../data/rfc/rfc2990.txt- Such measurement methodologies appear to fall within the realm of
../data/rfc/rfc2990.txt- additional refinement to the QoS architecture.
../data/rfc/rfc2990.txt-
../data/rfc/rfc2990.txt:3.9 QoS Accounting
../data/rfc/rfc2990.txt-
../data/rfc/rfc2990.txt- It is reasonable to anticipate that such forms of premium service and
../data/rfc/rfc2990.txt- customized service will attract an increment on the service tariff.
../data/rfc/rfc2990.txt- The provision of a distinguished service is undertaken with some
../data/rfc/rfc2990.txt- level of additional network resources to support the service, and the
--
../data/rfc/rfc2990.txt- those clients who are requesting a disproportionate level of
../data/rfc/rfc2990.txt- resources, but it provides a means to control the level of demand for
../data/rfc/rfc2990.txt- premium service levels.
../data/rfc/rfc2990.txt-
../data/rfc/rfc2990.txt- If there are to be incremental tariffs on the use of premium
../data/rfc/rfc2990.txt: services, then some accounting of the use of the premium service
../data/rfc/rfc2990.txt- would appear to be necessary relating use of the service to a
../data/rfc/rfc2990.txt- particular client. So far there is no definition of such an
../data/rfc/rfc2990.txt: accounting model nor a definition as to how to gather the data to
../data/rfc/rfc2990.txt: support the resource accounting function.
../data/rfc/rfc2990.txt-
../data/rfc/rfc2990.txt- The impact of this QoS service model may be quite profound to the
../data/rfc/rfc2990.txt- models of Internet service provision. The commonly adopted model in
../data/rfc/rfc2990.txt- both the public internet and within enterprise networks is that of a
../data/rfc/rfc2990.txt- model of access, where the clients service tariff is based on the
../data/rfc/rfc2990.txt- characteristics of access to the services, rather than that of the
../data/rfc/rfc2990.txt- actual use of the service. The introduction of QoS services creates
../data/rfc/rfc2990.txt- a strong impetus to move to usage-based tariffs, where the tariff is
../data/rfc/rfc2990.txt- based on the level of use of the network's resources. This, in turn,
../data/rfc/rfc2990.txt- generates a requirement to meter resource use, which is a form of
../data/rfc/rfc2990.txt: usage accounting. This topic was been previously studied within the
../data/rfc/rfc2990.txt-
../data/rfc/rfc2990.txt-
../data/rfc/rfc2990.txt-
../data/rfc/rfc2990.txt-Huston Informational [Page 15]
../data/rfc/rfc2990.txt-
../data/rfc/rfc2990.txt-RFC 2990 Next Steps for QoS Architecture November 2000
../data/rfc/rfc2990.txt-
../data/rfc/rfc2990.txt-
../data/rfc/rfc2990.txt: IETF under the topic of "Internet Accounting" [11], and further
../data/rfc/rfc2990.txt- refinement of the concepts used in this model, as they apply to QoS
../data/rfc/rfc2990.txt: accounting may prove to be a productive initial step in formulating a
../data/rfc/rfc2990.txt: standards-based model for QoS accounting.
../data/rfc/rfc2990.txt-
../data/rfc/rfc2990.txt-3.10 QoS Deployment Diversity
../data/rfc/rfc2990.txt-
../data/rfc/rfc2990.txt- It is extremely improbable that any single form of service
../data/rfc/rfc2990.txt- differentiation technology will be rolled out across the Internet and
--
../data/rfc/rfc2990.txt- implementation of fairness of access to the common transmission and
../data/rfc/rfc2990.txt- switching resource. The introduction of any form of fairness, and,
../data/rfc/rfc2990.txt- in the case of QoS, weighted fairness, implies a requirement for
../data/rfc/rfc2990.txt- transparency in the implementation of the fairness contract between
../data/rfc/rfc2990.txt- the network provider and the network's users. This requires some
../data/rfc/rfc2990.txt: form of resource accounting and auditing, which, in turn, requires
../data/rfc/rfc2990.txt- the use of authentication and access control. The balancing factor
../data/rfc/rfc2990.txt- is that a shared resource should not overtly expose the level of
../data/rfc/rfc2990.txt- resource usage of any one user to any other, so that some level of
../data/rfc/rfc2990.txt- secrecy is required in this environment
../data/rfc/rfc2990.txt-
--
../data/rfc/rfc2990.txt- 1998.
../data/rfc/rfc2990.txt-
../data/rfc/rfc2990.txt- [10] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data
../data/rfc/rfc2990.txt- Flows", RFC 2007, September 1997.
../data/rfc/rfc2990.txt-
../data/rfc/rfc2990.txt: [11] Mills, C., Hirsh, D. and G. Ruth, "Internet Accounting:
../data/rfc/rfc2990.txt- Background", RFC 1272, November 1991.
../data/rfc/rfc2990.txt-
../data/rfc/rfc2990.txt-9. Acknowledgments
../data/rfc/rfc2990.txt-
../data/rfc/rfc2990.txt- Valuable contributions to this document came from Yoram Bernet, Brian
--
../data/rfc/rfc5080.txt- 2.1.2. Request-ID Supplementation ..........................6
../data/rfc/rfc5080.txt- 2.2. Overload Conditions ........................................7
../data/rfc/rfc5080.txt- 2.2.1. Retransmission Behavior .............................7
../data/rfc/rfc5080.txt- 2.2.2. Duplicate Detection and Orderly Delivery ...........10
../data/rfc/rfc5080.txt- 2.2.3. Server Response to Overload ........................11
../data/rfc/rfc5080.txt: 2.3. Accounting Issues .........................................12
../data/rfc/rfc5080.txt- 2.3.1. Attributes Allowed in an Interim Update ............12
../data/rfc/rfc5080.txt- 2.3.2. Acct-Session-Id and Acct-Multi-Session-Id ..........12
../data/rfc/rfc5080.txt- 2.3.3. Request Authenticator ..............................13
../data/rfc/rfc5080.txt: 2.3.4. Interim-Accounting-Interval ........................13
../data/rfc/rfc5080.txt- 2.3.5. Counter Values in the RADIUS Management
../data/rfc/rfc5080.txt- Information Base (MIB) .............................14
../data/rfc/rfc5080.txt- 2.4. Multiple Filter-ID Attributes .............................15
../data/rfc/rfc5080.txt- 2.5. Mandatory and Optional Attributes .........................16
../data/rfc/rfc5080.txt- 2.6. Interpretation of Access-Reject ...........................18
--
../data/rfc/rfc5080.txt- Each service provided by the NAS to a peer constitutes a session,
../data/rfc/rfc5080.txt- with the beginning of the session defined as the point where
../data/rfc/rfc5080.txt- service is first provided, and the end of the session is defined
../data/rfc/rfc5080.txt- as the point where service is ended. A peer may have multiple
../data/rfc/rfc5080.txt- sessions in parallel or series if the NAS supports that, with each
../data/rfc/rfc5080.txt: session generating a separate start and stop accounting record.
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt- silently discard
../data/rfc/rfc5080.txt- This means the implementation discards the packet without further
../data/rfc/rfc5080.txt- processing. The implementation SHOULD provide the capability of
../data/rfc/rfc5080.txt- logging the error, including the contents of the silently
--
../data/rfc/rfc5080.txt- retransmission mechanism described below. Other retransmission
../data/rfc/rfc5080.txt- mechanisms are possible, as long as they satisfy the requirements on
../data/rfc/rfc5080.txt- jitter and congestive backoff.
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt- The following algorithms apply to any client that originates RADIUS
../data/rfc/rfc5080.txt: packets, including but not limited to Access-Request, Accounting-
../data/rfc/rfc5080.txt- Request, Disconnect-Request, and CoA-Request [RFC3576].
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt- The retransmission behavior is controlled and described by the
../data/rfc/rfc5080.txt- following variables:
../data/rfc/rfc5080.txt-
--
../data/rfc/rfc5080.txt- once MRD seconds have elapsed since the client first transmitted the
../data/rfc/rfc5080.txt- message. If MRC is non-zero, the message exchange fails when either
../data/rfc/rfc5080.txt- the sender has transmitted the message MRC times, or when MRD seconds
../data/rfc/rfc5080.txt- have elapsed since the client first transmitted the message.
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt: For Accounting-Request packets, the default values for MRC, MRD, and
../data/rfc/rfc5080.txt- MRT SHOULD be zero. These settings will enable a RADIUS client to
../data/rfc/rfc5080.txt: continue sending accounting requests to a RADIUS server until the
../data/rfc/rfc5080.txt- request is acknowledged. If any of MRC, MRD, or MRT are non-zero,
../data/rfc/rfc5080.txt: then the accounting information could potentially be discarded
../data/rfc/rfc5080.txt- without being recorded.
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt-
--
../data/rfc/rfc5080.txt- processing new requests from a NAS.
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt- These methods will allow some users to gain access to the network,
../data/rfc/rfc5080.txt- reducing the load created by ongoing access attempts.
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt:2.3. Accounting Issues
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt-2.3.1. Attributes Allowed in an Interim Update
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt- [RFC2866] indicates that Acct-Input-Octets, Acct-Output-Octets,
../data/rfc/rfc5080.txt- Acct-Session-Time, Acct-Input-Packets, Acct-Output-Packets and Acct-
../data/rfc/rfc5080.txt: Terminate-Cause attributes "can only be present in Accounting-Request
../data/rfc/rfc5080.txt- records where the Acct-Status-Type is set to Stop".
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt- However [RFC2869] Section 2.1 states:
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt: It is envisioned that an Interim Accounting record (with Acct-
../data/rfc/rfc5080.txt- Status-Type = Interim-Update (3)) would contain all of the
../data/rfc/rfc5080.txt: attributes normally found in an Accounting Stop message with the
../data/rfc/rfc5080.txt- exception of the Acct-Term-Cause attribute.
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt- Although [RFC2869] does not indicate that it updates [RFC2866], this
../data/rfc/rfc5080.txt- is an oversight, and the above attributes are allowable in an Interim
../data/rfc/rfc5080.txt: Accounting record.
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt-2.3.2. Acct-Session-Id and Acct-Multi-Session-Id
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt- [RFC2866] Section 5.5 describes Acct-Session-Id as Text within the
../data/rfc/rfc5080.txt- figure summarizing the attribute format, but then goes on to state
--
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt-2.3.3. Request Authenticator
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt- [RFC2866] Section 4.1 states:
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt: The Request Authenticator of an Accounting-Request contains a 16-
../data/rfc/rfc5080.txt- octet MD5 hash value calculated according to the method described
../data/rfc/rfc5080.txt- in "Request Authenticator" above.
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt- However, the text does not indicate any action to take when an
../data/rfc/rfc5080.txt: Accounting-Request packet contains an invalid Request Authenticator.
../data/rfc/rfc5080.txt- The following text should be considered to be part of the above
../data/rfc/rfc5080.txt- description:
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt- The Request Authenticator field MUST contain the correct data, as
../data/rfc/rfc5080.txt- given by the above calculation. Invalid packets are silently
--
../data/rfc/rfc5080.txt- Request Authenticator to all zeros. New implementations of RADIUS
../data/rfc/rfc5080.txt- clients MUST use the above algorithm to calculate the Request
../data/rfc/rfc5080.txt- Authenticator field. New RADIUS server implementations MUST
../data/rfc/rfc5080.txt- silently discard invalid packets.
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt:2.3.4. Interim-Accounting-Interval
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt- [RFC2869] Section 2.1 states:
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt- It is also possible to statically configure an interim value on
../data/rfc/rfc5080.txt- the NAS itself. Note that a locally configured value on the NAS
../data/rfc/rfc5080.txt- MUST override the value found in an Access-Accept.
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt- This requirement may be phrased too strongly. It is conceivable that
../data/rfc/rfc5080.txt- a NAS implementation has a setting for a "minimum" value of Interim-
../data/rfc/rfc5080.txt: Accounting-Interval, based on resource constraints in the NAS, and
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt-Nelson & DeKok Standards Track [Page 13]
../data/rfc/rfc5080.txt-
--
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt- network loading in the local environment of the NAS. In such cases,
../data/rfc/rfc5080.txt- the value administratively provisioned in the NAS should not be
../data/rfc/rfc5080.txt- over-ridden by a smaller value from an Access-Accept message. The
../data/rfc/rfc5080.txt- NAS's value could be over-ridden by a larger one, however. The
../data/rfc/rfc5080.txt: intent is that the NAS sends accounting information at fixed
../data/rfc/rfc5080.txt- intervals that are short enough so that the potential loss of
../data/rfc/rfc5080.txt: billable revenue is limited, but also that the accounting updates are
../data/rfc/rfc5080.txt- infrequent enough so that the NAS, network, and RADIUS server are not
../data/rfc/rfc5080.txt- overloaded.
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt-2.3.5. Counter Values in the RADIUS Management Information Base (MIB)
../data/rfc/rfc5080.txt-
--
../data/rfc/rfc5080.txt- treated as Access-Rejects. If the flag is set to false, then unknown
../data/rfc/rfc5080.txt- attributes in Access-Accepts are silently ignored.
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt- On receiving a packet including an attribute of unknown Type, RADIUS
../data/rfc/rfc5080.txt- authentication server implementations SHOULD ignore such attributes.
../data/rfc/rfc5080.txt: However, RADIUS accounting server implementations typically do not
../data/rfc/rfc5080.txt- need to understand attributes in order to write them to stable
../data/rfc/rfc5080.txt: storage or pass them to the billing engine. Therefore, accounting
../data/rfc/rfc5080.txt- server implementations SHOULD be equipped to handle unknown
../data/rfc/rfc5080.txt- attributes.
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt- To avoid misinterpretation of service requests encoded within VSAs,
../data/rfc/rfc5080.txt- RADIUS servers SHOULD NOT send VSAs containing service requests to
--
../data/rfc/rfc5080.txt- used only for ARAP authentication.
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt-2.6.2. Service Request Denial
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt- RADIUS has been deployed for purposes outside network access
../data/rfc/rfc5080.txt: authentication, authorization, and accounting. For example, RADIUS
../data/rfc/rfc5080.txt- has been deployed as a "back-end" for authenticating Voice Over IP
../data/rfc/rfc5080.txt- (VOIP) connections, Hypertext Transfer Protocol (HTTP) sessions
../data/rfc/rfc5080.txt- (e.g., Apache), File Transfer Protocol (FTP) sessions (e.g.,
../data/rfc/rfc5080.txt- proftpd), and machine logins for multiple operating systems (e.g.,
../data/rfc/rfc5080.txt- bsdi, pam, and gina). In those contexts, an Access-Reject sent to
--
../data/rfc/rfc5080.txt- the utility of the cache. This attack can be mitigated by following
../data/rfc/rfc5080.txt- the suggestions in [RFC3579] Section 4, or by requiring the presence
../data/rfc/rfc5080.txt- of Message-Authenticator, as described in Sections 2.1.1 and 2.2.2.
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt- Since this document describes the use of RADIUS for purposes of
../data/rfc/rfc5080.txt: authentication, authorization, and accounting in a wide variety of
../data/rfc/rfc5080.txt- networks, applications using these specifications are vulnerable to
../data/rfc/rfc5080.txt- all of the threats that are present in other RADIUS applications.
../data/rfc/rfc5080.txt- For a discussion of these threats, see [RFC2865], [RFC2607],
../data/rfc/rfc5080.txt- [RFC3162], [RFC3579], and [RFC3580].
../data/rfc/rfc5080.txt-
--
../data/rfc/rfc5080.txt- Implementation in Roaming", RFC 2607, June 1999.
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt- [RFC2618] Aboba, B. and G. Zorn, "RADIUS Authentication Client
../data/rfc/rfc5080.txt- MIB", RFC 2618, June 1999.
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt- [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS
../data/rfc/rfc5080.txt- Extensions", RFC 2869, June 2000.
../data/rfc/rfc5080.txt-
../data/rfc/rfc5080.txt- [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
--
../data/rfc/rfc2804.txt- Thus, for instance, monitoring public newsgroups is not wiretapping
../data/rfc/rfc2804.txt- (condition 3 violated), random monitoring of a large population is
../data/rfc/rfc2804.txt- not wiretapping (condition 4 violated), a recipient passing on
../data/rfc/rfc2804.txt- private email is not wiretapping (condition 2 violated).
../data/rfc/rfc2804.txt-
../data/rfc/rfc2804.txt: An Internet equivalent of call tracing by means of accounting logs
../data/rfc/rfc2804.txt- (sometimes called "pen registers") that is a feature of the telephone
../data/rfc/rfc2804.txt- network is also wiretapping by this definition, since the normal
../data/rfc/rfc2804.txt: expectation of the sender is that the company doing the accounting
../data/rfc/rfc2804.txt- will keep this information in confidence.
../data/rfc/rfc2804.txt-
../data/rfc/rfc2804.txt- Wiretapping may logically be thought of as 3 distinct steps:
../data/rfc/rfc2804.txt-
../data/rfc/rfc2804.txt- - Capture - getting information off the wire that contains the
--
../data/rfc/rfc2804.txt- - Whether the wiretap is legal or not, since that is a legal, not a
../data/rfc/rfc2804.txt- technical matter.
../data/rfc/rfc2804.txt-
../data/rfc/rfc2804.txt- - Whether the wiretap occurs in real time, or can be performed after
../data/rfc/rfc2804.txt- the fact by looking at information recorded for other purposes
../data/rfc/rfc2804.txt: (such as the accounting example given above).
../data/rfc/rfc2804.txt-
../data/rfc/rfc2804.txt- - What the medium targeted by the wiretap is - whether it is email,
../data/rfc/rfc2804.txt- IP telephony, Web browsing or EDI transfers.
../data/rfc/rfc2804.txt-
../data/rfc/rfc2804.txt- These questions are believed to be irrelevant to the policy outlined
--
../data/rfc/rfc8581.txt-
../data/rfc/rfc8581.txt-
../data/rfc/rfc8581.txt-8. IANA Considerations
../data/rfc/rfc8581.txt-
../data/rfc/rfc8581.txt- IANA has registered the following values in the "Authentication,
../data/rfc/rfc8581.txt: Authorization, and Accounting (AAA) Parameters" registry:
../data/rfc/rfc8581.txt-
../data/rfc/rfc8581.txt- Two new AVP codes are defined in Section 7.4.
../data/rfc/rfc8581.txt-
../data/rfc/rfc8581.txt- Note that the values used for the OC-Peer-Algo AVP are a subset of
../data/rfc/rfc8581.txt- the "OC-Feature-Vector AVP Values (code 622)" registry. Only the
--
../data/rfc/rfc7921.txt- policy that is contained in a set of access control rules.
../data/rfc/rfc7921.txt- Similarly, it is expected the I2RS identity links to one role that
../data/rfc/rfc7921.txt- has a scope policy specified by a set of access control rules. This
../data/rfc/rfc7921.txt- scope policy can be provided via Local Configuration, exposed as an
../data/rfc/rfc7921.txt- I2RS service for manipulation by authorized clients, or via some
../data/rfc/rfc7921.txt: other method (e.g., Authentication, Authorization, and Accounting
../data/rfc/rfc7921.txt- (AAA) service)
../data/rfc/rfc7921.txt-
../data/rfc/rfc7921.txt- While the I2RS agent allows access based on the I2RS client's scope
../data/rfc/rfc7921.txt- policy, this does not mean the access is required to arrive on a
../data/rfc/rfc7921.txt- particular transport connection or from a particular I2RS client by
--
../data/rfc/rfc2975.txt- D. Harrington
../data/rfc/rfc2975.txt- Cabletron Systems Inc.
../data/rfc/rfc2975.txt- October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Introduction to Accounting Management
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Status of this Memo
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- This memo provides information for the Internet community. It does
../data/rfc/rfc2975.txt- not specify an Internet standard of any kind. Distribution of this
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Copyright (C) The Internet Society (2000). All Rights Reserved.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Abstract
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: The field of Accounting Management is concerned with the collection
../data/rfc/rfc2975.txt- of resource consumption data for the purposes of capacity and trend
../data/rfc/rfc2975.txt- analysis, cost allocation, auditing, and billing. This document
../data/rfc/rfc2975.txt- describes each of these problems, and discusses the issues involved
../data/rfc/rfc2975.txt: in design of modern accounting systems.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Since accounting applications do not have uniform security and
../data/rfc/rfc2975.txt- reliability requirements, it is not possible to devise a single
../data/rfc/rfc2975.txt: accounting protocol and set of security services that will meet all
../data/rfc/rfc2975.txt: needs. Thus the goal of accounting management is to provide a set of
../data/rfc/rfc2975.txt- tools that can be used to meet the requirements of each application.
../data/rfc/rfc2975.txt- This document describes the currently available tools as well as the
../data/rfc/rfc2975.txt: state of the art in accounting protocol design. A companion
../data/rfc/rfc2975.txt: document, RFC 2924, reviews the state of the art in accounting
../data/rfc/rfc2975.txt- attributes and record formats.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 1]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Table of Contents
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- 1. Introduction 2
../data/rfc/rfc2975.txt- 1.1 Requirements language 3
../data/rfc/rfc2975.txt- 1.2 Terminology 3
../data/rfc/rfc2975.txt: 1.3 Accounting management architecture 5
../data/rfc/rfc2975.txt: 1.4 Accounting management objectives 7
../data/rfc/rfc2975.txt: 1.5 Intra-domain and inter-domain accounting 10
../data/rfc/rfc2975.txt: 1.6 Accounting record production 11
../data/rfc/rfc2975.txt- 1.7 Requirements summary 13
../data/rfc/rfc2975.txt- 2. Scaling and reliability 14
../data/rfc/rfc2975.txt- 2.1 Fault resilience 14
../data/rfc/rfc2975.txt- 2.2 Resource consumption 23
../data/rfc/rfc2975.txt- 2.3 Data collection models 26
../data/rfc/rfc2975.txt: 3. Review of Accounting Protocols 32
../data/rfc/rfc2975.txt- 3.1 RADIUS 32
../data/rfc/rfc2975.txt- 3.2 TACACS+ 33
../data/rfc/rfc2975.txt- 3.3 SNMP 33
../data/rfc/rfc2975.txt: 4. Review of Accounting Data Transfer 43
../data/rfc/rfc2975.txt- 4.1 SMTP 44
../data/rfc/rfc2975.txt- 4.2 Other protocols 44
../data/rfc/rfc2975.txt- 5. Summary 45
../data/rfc/rfc2975.txt- 6. Security Considerations 48
../data/rfc/rfc2975.txt- 7. Acknowledgments 48
--
../data/rfc/rfc2975.txt- 10. Intellectual Property Statement 53
../data/rfc/rfc2975.txt- 11. Full Copyright Statement 54
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-1. Introduction
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: The field of Accounting Management is concerned with the collection
../data/rfc/rfc2975.txt- of resource consumption data for the purposes of capacity and trend
../data/rfc/rfc2975.txt- analysis, cost allocation, auditing, and billing. This document
../data/rfc/rfc2975.txt- describes each of these problems, and discusses the issues involved
../data/rfc/rfc2975.txt: in design of modern accounting systems.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Since accounting applications do not have uniform security and
../data/rfc/rfc2975.txt- reliability requirements, it is not possible to devise a single
../data/rfc/rfc2975.txt: accounting protocol and set of security services that will meet all
../data/rfc/rfc2975.txt: needs. Thus the goal of accounting management is to provide a set of
../data/rfc/rfc2975.txt- tools that can be used to meet the requirements of each application.
../data/rfc/rfc2975.txt- This document describes the currently available tools as well as the
../data/rfc/rfc2975.txt: state of the art in accounting protocol design. A companion
../data/rfc/rfc2975.txt: document, RFC 2924, reviews the state of the art in accounting
../data/rfc/rfc2975.txt- attributes and record formats.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 2]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-1.1. Requirements language
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-1.2. Terminology
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- This document frequently uses the following terms:
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Accounting
../data/rfc/rfc2975.txt- The collection of resource consumption data for the
../data/rfc/rfc2975.txt- purposes of capacity and trend analysis, cost allocation,
../data/rfc/rfc2975.txt: auditing, and billing. Accounting management requires that
../data/rfc/rfc2975.txt- resource consumption be measured, rated, assigned, and
../data/rfc/rfc2975.txt- communicated between appropriate parties.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Archival accounting
../data/rfc/rfc2975.txt: In archival accounting, the goal is to collect all
../data/rfc/rfc2975.txt: accounting data, to reconstruct missing entries as best as
../data/rfc/rfc2975.txt- possible in the event of data loss, and to archive data for
../data/rfc/rfc2975.txt- a mandated time period. It is "usual and customary" for
../data/rfc/rfc2975.txt- these systems to be engineered to be very robust against
../data/rfc/rfc2975.txt: accounting data loss. This may include provisions for
../data/rfc/rfc2975.txt- transport layer as well as application layer
../data/rfc/rfc2975.txt- acknowledgments, use of non-volatile storage, interim
../data/rfc/rfc2975.txt: accounting capabilities (stored or transmitted over the
../data/rfc/rfc2975.txt- wire), etc. Legal or financial requirements frequently
../data/rfc/rfc2975.txt: mandate archival accounting practices, and may often
../data/rfc/rfc2975.txt- dictate that data be kept confidential, regardless of
../data/rfc/rfc2975.txt- whether it is to be used for billing purposes or not.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Rating The act of determining the price to be charged for use of a
../data/rfc/rfc2975.txt- resource.
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 3]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- the recommended process. Accomplishing this may require
../data/rfc/rfc2975.txt- security services such as authentication and integrity
../data/rfc/rfc2975.txt- protection.
--
../data/rfc/rfc2975.txt- the objective is to determine the amount to be charged for
../data/rfc/rfc2975.txt- use of a resource. In cost allocation, the cost per unit
../data/rfc/rfc2975.txt- of resource may need to be determined; in rating, this is
../data/rfc/rfc2975.txt- typically a given.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Interim accounting
../data/rfc/rfc2975.txt: Interim accounting provides a snapshot of usage during a
../data/rfc/rfc2975.txt- user's session. This may be useful in the event of a
../data/rfc/rfc2975.txt- device reboot or other network problem that prevents the
../data/rfc/rfc2975.txt- reception or generation of a session summary packet or
../data/rfc/rfc2975.txt: session record. Interim accounting records can always be
../data/rfc/rfc2975.txt- summarized without the loss of information. Note that
../data/rfc/rfc2975.txt: interim accounting records may be stored internally on the
../data/rfc/rfc2975.txt- device (such as in non-volatile storage) so as to survive a
../data/rfc/rfc2975.txt- reboot and thus may not always be transmitted over the
../data/rfc/rfc2975.txt- wire.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Session record
../data/rfc/rfc2975.txt- A session record represents a summary of the resource
../data/rfc/rfc2975.txt: consumption of a user over the entire session. Accounting
../data/rfc/rfc2975.txt- gateways creating the session record may do so by
../data/rfc/rfc2975.txt: processing interim accounting events or accounting events
../data/rfc/rfc2975.txt- from several devices serving the same user.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Accounting Protocol
../data/rfc/rfc2975.txt: A protocol used to convey data for accounting purposes.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Intra-domain accounting
../data/rfc/rfc2975.txt: Intra-domain accounting involves the collection of
../data/rfc/rfc2975.txt- information on resource usage within an administrative
../data/rfc/rfc2975.txt- domain, for use within that domain. In intra-domain
../data/rfc/rfc2975.txt: accounting, accounting packets and session records
../data/rfc/rfc2975.txt- typically do not cross administrative boundaries.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Inter-domain accounting
../data/rfc/rfc2975.txt: Inter-domain accounting involves the collection of
../data/rfc/rfc2975.txt- information on resource usage within an administrative
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 4]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- domain, for use within another administrative domain. In
../data/rfc/rfc2975.txt: inter-domain accounting, accounting packets and session
../data/rfc/rfc2975.txt- records will typically cross administrative boundaries.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Real-time accounting
../data/rfc/rfc2975.txt: Real-time accounting involves the processing of information
../data/rfc/rfc2975.txt- on resource usage within a defined time window. Time
../data/rfc/rfc2975.txt- constraints are typically imposed in order to limit
../data/rfc/rfc2975.txt- financial risk.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Accounting server
../data/rfc/rfc2975.txt: The accounting server receives accounting data from devices
../data/rfc/rfc2975.txt: and translates it into session records. The accounting
../data/rfc/rfc2975.txt- server may also take responsibility for the routing of
../data/rfc/rfc2975.txt- session records to interested parties.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:1.3. Accounting management architecture
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: The accounting management architecture involves interactions between
../data/rfc/rfc2975.txt: network devices, accounting servers, and billing servers. The
../data/rfc/rfc2975.txt- network device collects resource consumption data in the form of
../data/rfc/rfc2975.txt: accounting metrics. This information is then transferred to an
../data/rfc/rfc2975.txt: accounting server. Typically this is accomplished via an accounting
../data/rfc/rfc2975.txt- protocol, although it is also possible for devices to generate their
../data/rfc/rfc2975.txt- own session records.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: The accounting server then processes the accounting data received
../data/rfc/rfc2975.txt- from the network device. This processing may include summarization
../data/rfc/rfc2975.txt: of interim accounting information, elimination of duplicate data, or
../data/rfc/rfc2975.txt- generation of session records.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: The processed accounting data is then submitted to a billing server,
../data/rfc/rfc2975.txt- which typically handles rating and invoice generation, but may also
../data/rfc/rfc2975.txt- carry out auditing, cost allocation, trend analysis or capacity
../data/rfc/rfc2975.txt- planning functions. Session records may be batched and compressed by
../data/rfc/rfc2975.txt: the accounting server prior to submission to the billing server in
../data/rfc/rfc2975.txt: order to reduce the volume of accounting data and the bandwidth
../data/rfc/rfc2975.txt- required to accomplish the transfer.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: One of the functions of the accounting server is to distinguish
../data/rfc/rfc2975.txt: between inter and intra-domain accounting events and to route them
../data/rfc/rfc2975.txt- appropriately. For session records containing a Network Access
../data/rfc/rfc2975.txt- Identifier (NAI), described in [8], the distinction can be made by
../data/rfc/rfc2975.txt- examining the domain portion of the NAI. If the domain portion is
../data/rfc/rfc2975.txt- absent or corresponds to the local domain, then the session record is
../data/rfc/rfc2975.txt: treated as an intra-domain accounting event. Otherwise, it is
../data/rfc/rfc2975.txt: treated as an inter-domain accounting event.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 5]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Intra-domain accounting events are typically routed to the local
../data/rfc/rfc2975.txt: billing server, while inter-domain accounting events will be routed
../data/rfc/rfc2975.txt: to accounting servers operating within other administrative domains.
../data/rfc/rfc2975.txt- While it is not required that session record formats used in inter
../data/rfc/rfc2975.txt: and intra-domain accounting be the same, this is desirable, since it
../data/rfc/rfc2975.txt- eliminates translations that would otherwise be required.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Where a proxy forwarder is employed, domain-based access controls may
../data/rfc/rfc2975.txt- be employed by the proxy forwarder, rather than by the devices
../data/rfc/rfc2975.txt: themselves. The network device will typically speak an accounting
../data/rfc/rfc2975.txt- protocol to the proxy forwarder, which may then either convert the
../data/rfc/rfc2975.txt: accounting packets to session records, or forward the accounting
../data/rfc/rfc2975.txt- packets to another domain. In either case, domain separation is
../data/rfc/rfc2975.txt- typically achieved by having the proxy forwarder sort the session
../data/rfc/rfc2975.txt: records or accounting messages by destination.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Where the accounting proxy is not trusted, it may be difficult to
../data/rfc/rfc2975.txt- verify that the proxy is issuing correct session records based on the
../data/rfc/rfc2975.txt: accounting messages it receives, since the original accounting
../data/rfc/rfc2975.txt- messages typically are not forwarded along with the session records.
../data/rfc/rfc2975.txt- Therefore where trust is an issue, the proxy typically forwards the
../data/rfc/rfc2975.txt: accounting packets themselves. Assuming that the accounting protocol
../data/rfc/rfc2975.txt- supports data object security, this allows the end-points to verify
../data/rfc/rfc2975.txt- that the proxy has not modified the data in transit or snooped on the
../data/rfc/rfc2975.txt- packet contents.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 6]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: The diagram below illustrates the accounting management architecture:
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- +------------+
../data/rfc/rfc2975.txt- | |
../data/rfc/rfc2975.txt- | Network |
../data/rfc/rfc2975.txt- | Device |
../data/rfc/rfc2975.txt- | |
../data/rfc/rfc2975.txt- +------------+
../data/rfc/rfc2975.txt- |
../data/rfc/rfc2975.txt: Accounting |
../data/rfc/rfc2975.txt- Protocol |
../data/rfc/rfc2975.txt- |
../data/rfc/rfc2975.txt- V
../data/rfc/rfc2975.txt- +------------+ +------------+
../data/rfc/rfc2975.txt- | | | |
../data/rfc/rfc2975.txt- | Org B | Inter-domain session records | Org A |
../data/rfc/rfc2975.txt- | Acctg. |<----------------------------->| Acctg. |
../data/rfc/rfc2975.txt: |Proxy/Server| or accounting protocol | Server |
../data/rfc/rfc2975.txt- | | | |
../data/rfc/rfc2975.txt- +------------+ +------------+
../data/rfc/rfc2975.txt- | |
../data/rfc/rfc2975.txt- | |
../data/rfc/rfc2975.txt- Transfer | Intra-domain |
--
../data/rfc/rfc2975.txt- | Billing | | Billing |
../data/rfc/rfc2975.txt- | Server | | Server |
../data/rfc/rfc2975.txt- | | | |
../data/rfc/rfc2975.txt- +------------+ +------------+
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:1.4. Accounting management objectives
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Accounting Management involves the collection of resource consumption
../data/rfc/rfc2975.txt- data for the purposes of capacity and trend analysis, cost
../data/rfc/rfc2975.txt- allocation, auditing, billing. Each of these tasks has different
../data/rfc/rfc2975.txt- requirements.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-1.4.1. Trend analysis and capacity planning
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 7]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- requirements while still providing the forecast with the desired
../data/rfc/rfc2975.txt- statistical accuracy, it may be possible to tolerate high packet loss
../data/rfc/rfc2975.txt- as long as bias is not introduced.
--
../data/rfc/rfc2975.txt- inter-domain applications confidentiality may be desirable to guard
../data/rfc/rfc2975.txt- against snooping by third parties.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-1.4.2. Billing
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: When accounting data is used for billing purposes, the requirements
../data/rfc/rfc2975.txt- depend on whether the billing process is usage-sensitive or not.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-1.4.2.1. Non-usage sensitive billing
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Since by definition, non-usage-sensitive billing does not require
../data/rfc/rfc2975.txt: usage information, in theory all accounting data can be lost without
../data/rfc/rfc2975.txt- affecting the billing process. Of course this would also affect
../data/rfc/rfc2975.txt- other tasks such as trend analysis or auditing, so that such
../data/rfc/rfc2975.txt- wholesale data loss would still be unacceptable.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-1.4.2.2. Usage-sensitive billing
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Since usage-sensitive billing processes depend on usage information,
../data/rfc/rfc2975.txt- packet loss may translate directly to revenue loss. As a result, the
../data/rfc/rfc2975.txt- billing process may need to conform to financial reporting and legal
../data/rfc/rfc2975.txt: requirements, and therefore an archival accounting approach may be
../data/rfc/rfc2975.txt- needed.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Usage-sensitive systems may also require low processing delay. Today
../data/rfc/rfc2975.txt- credit risk is commonly managed by computerized fraud detection
../data/rfc/rfc2975.txt- systems that are designed to detect unusual activity. While
../data/rfc/rfc2975.txt- efficiency concerns might otherwise dictate batched transmission of
../data/rfc/rfc2975.txt: accounting data, where there is a risk of fraud, financial exposure
../data/rfc/rfc2975.txt- increases with processing delay. Thus it may be advisable to
../data/rfc/rfc2975.txt- transmit each event individually to minimize batch size, or even to
../data/rfc/rfc2975.txt- utilize quality of service techniques to minimize queuing delays. In
../data/rfc/rfc2975.txt- addition, it may be necessary for authorization to be dependent on
../data/rfc/rfc2975.txt- ability to pay.
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 8]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Whether these techniques will be useful varies by application since
../data/rfc/rfc2975.txt- the degree of financial exposure is application-dependent. For
../data/rfc/rfc2975.txt- dial-up Internet access from a local provider, charges are typically
--
../data/rfc/rfc2975.txt- ability to pay. In situations where valuable resources can be
../data/rfc/rfc2975.txt- reserved, or where charges can be high, very large bills may be rung
../data/rfc/rfc2975.txt- up quickly, and processing may need to be completed within a defined
../data/rfc/rfc2975.txt- time window in order to limit exposure.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Since in usage-sensitive systems, accounting data translates into
../data/rfc/rfc2975.txt- revenue, the security and reliability requirements are greater. Due
../data/rfc/rfc2975.txt- to financial and legal requirements such systems need to be able to
../data/rfc/rfc2975.txt- survive an audit. Thus security services such as authentication,
../data/rfc/rfc2975.txt- integrity and replay protection are frequently required and
../data/rfc/rfc2975.txt- confidentiality and data object integrity may also be desirable.
../data/rfc/rfc2975.txt- Application-layer acknowledgments are also often required so as to
../data/rfc/rfc2975.txt: guard against accounting server failures.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-1.4.3. Auditing
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- With enterprise networking expenditures on the rise, interest in
../data/rfc/rfc2975.txt- auditing is increasing. Auditing, which is the act of verifying the
../data/rfc/rfc2975.txt: correctness of a procedure, commonly relies on accounting data.
../data/rfc/rfc2975.txt- Auditing tasks include verifying the correctness of an invoice
../data/rfc/rfc2975.txt- submitted by a service provider, or verifying conformance to usage
../data/rfc/rfc2975.txt- policy, service level agreements, or security guidelines.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- To permit a credible audit, the auditing data collection process must
../data/rfc/rfc2975.txt: be at least as reliable as the accounting process being used by the
../data/rfc/rfc2975.txt- entity that is being audited. Similarly, security policies for the
../data/rfc/rfc2975.txt- audit should be at least as stringent as those used in preparation of
../data/rfc/rfc2975.txt- the original invoice. Due to financial and legal requirements,
../data/rfc/rfc2975.txt: archival accounting practices are frequently required in this
../data/rfc/rfc2975.txt- application.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Where auditing procedures are used to verify conformance to usage or
../data/rfc/rfc2975.txt- security policies, security services may be desired. This typically
../data/rfc/rfc2975.txt- will include authentication, integrity and replay protection as well
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 9]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-1.4.4. Cost allocation
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- The application of cost allocation and billback methods by enterprise
--
../data/rfc/rfc2975.txt- partners in a venture or to allocation of costs between departments
../data/rfc/rfc2975.txt- in a single firm, cost allocation models often have profound
../data/rfc/rfc2975.txt- behavioral and financial impacts. As a result, systems developed for
../data/rfc/rfc2975.txt- this purposes are typically as concerned with reliable data
../data/rfc/rfc2975.txt- collection and security as are billing applications. Due to
../data/rfc/rfc2975.txt: financial and legal requirements, archival accounting practices are
../data/rfc/rfc2975.txt- frequently required in this application.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:1.5. Intra-domain and inter-domain accounting
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Much of the initial work on accounting management has focused on
../data/rfc/rfc2975.txt: intra-domain accounting applications. However, with the increasing
../data/rfc/rfc2975.txt- deployment of services such as dial-up roaming, Internet fax, Voice
../data/rfc/rfc2975.txt- and Video over IP and QoS, applications requiring inter-domain
../data/rfc/rfc2975.txt: accounting are becoming increasingly common.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Inter-domain accounting differs from intra-domain accounting in
../data/rfc/rfc2975.txt: several important ways. Intra-domain accounting involves the
../data/rfc/rfc2975.txt- collection of information on resource consumption within an
../data/rfc/rfc2975.txt- administrative domain, for use within that domain. In intra-domain
../data/rfc/rfc2975.txt: accounting, accounting packets and session records typically do not
../data/rfc/rfc2975.txt- cross administrative boundaries. As a result, intra-domain
../data/rfc/rfc2975.txt: accounting applications typically experience low packet loss and
../data/rfc/rfc2975.txt- involve transfer of data between trusted entities.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: In contrast, inter-domain accounting involves the collection of
../data/rfc/rfc2975.txt- information on resource consumption within an administrative domain,
../data/rfc/rfc2975.txt- for use within another administrative domain. In inter-domain
../data/rfc/rfc2975.txt: accounting, accounting packets and session records will typically
../data/rfc/rfc2975.txt- cross administrative boundaries. As a result, inter-domain
../data/rfc/rfc2975.txt: accounting applications may experience substantial packet loss. In
../data/rfc/rfc2975.txt- addition, the entities involved in the transfers cannot be assumed to
../data/rfc/rfc2975.txt- trust each other.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 10]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Since inter-domain accounting applications involve transfers of
../data/rfc/rfc2975.txt: accounting data between domains, additional security measures may be
../data/rfc/rfc2975.txt- desirable. In addition to authentication, replay and integrity
../data/rfc/rfc2975.txt- protection, it may be desirable to deploy security services such as
../data/rfc/rfc2975.txt- confidentiality and data object integrity. In inter-domain
../data/rfc/rfc2975.txt: accounting each involved party also typically requires a copy of each
../data/rfc/rfc2975.txt: accounting event for invoice generation and auditing.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:1.6. Accounting record production
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Typically, a single accounting record is produced per session, or in
../data/rfc/rfc2975.txt- some cases, a set of interim records which can be summarized in a
../data/rfc/rfc2975.txt- single record for billing purposes. However, to support deployment
../data/rfc/rfc2975.txt- of services such as wireless access or complex billing regimes, a
../data/rfc/rfc2975.txt- more sophisticated approach is required.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: It is necessary to generate several accounting records from a single
../data/rfc/rfc2975.txt- session when pricing changes during a session. For instance, the
../data/rfc/rfc2975.txt- price of a service can be higher during peak hours than off-peak.
../data/rfc/rfc2975.txt- For a session continuing from one tariff period to another, it
../data/rfc/rfc2975.txt- becomes necessary for a device to report "packets sent" during both
../data/rfc/rfc2975.txt- periods.
--
../data/rfc/rfc2975.txt- while still being connected in the same session. If roaming causes a
../data/rfc/rfc2975.txt- change in the tariffs, it is necessary to account for resource
../data/rfc/rfc2975.txt- consumed in the first and second areas. Another example is where
../data/rfc/rfc2975.txt- modifications are allowed to an ongoing session. For example, it is
../data/rfc/rfc2975.txt- possible that a session could be re-authorized with improved QoS.
../data/rfc/rfc2975.txt: This would require production of accounting records at both QoS
../data/rfc/rfc2975.txt- levels.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- These examples could be addressed by using vectors or multi-
../data/rfc/rfc2975.txt- dimensional arrays to represent resource consumption within a single
../data/rfc/rfc2975.txt- session record. For example, the vector or array could describe the
../data/rfc/rfc2975.txt- resource consumption for each combination of factors, e.g. one data
../data/rfc/rfc2975.txt- item could be the number of packets during peak hour in the area of
../data/rfc/rfc2975.txt- the home operator. However, such an approach seems complicated and
../data/rfc/rfc2975.txt- inflexible and as a result, most current systems produce a set of
../data/rfc/rfc2975.txt- records from one session. A session identifier needs to be present
../data/rfc/rfc2975.txt: in the records to permit accounting systems to tie the records
../data/rfc/rfc2975.txt- together.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- In most cases, the network device will determine when multiple
../data/rfc/rfc2975.txt- session records are needed, as the local device is aware of factors
../data/rfc/rfc2975.txt- affecting local tariffs, such as QoS changes and roaming. However,
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 11]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: control the generation of accounting records. This is of importance
../data/rfc/rfc2975.txt: in inter-domain accounting or when network devices do not have tariff
../data/rfc/rfc2975.txt: information. The centralized control of accounting record production
../data/rfc/rfc2975.txt- can be realized, for instance, by having authorization servers
../data/rfc/rfc2975.txt- require re-authorization at certain times and requiring the
../data/rfc/rfc2975.txt: production of accounting records upon each re-authorization.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- In conclusion, in some cases it is necessary to produce multiple
../data/rfc/rfc2975.txt: accounting records from a single session. It must be possible to do
../data/rfc/rfc2975.txt- this without requiring the user to start a new session or to re-
../data/rfc/rfc2975.txt- authenticate. The production of multiple records can be controlled
../data/rfc/rfc2975.txt- either by the network device or by the AAA server. The requirements
../data/rfc/rfc2975.txt- for timeliness, security and reliability in multiple record sessions
../data/rfc/rfc2975.txt- are the same as for single-record sessions.
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 12]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-1.7. Requirements summary
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--
../data/rfc/rfc2975.txt- | Billing | replay protection | replay protection |
../data/rfc/rfc2975.txt- | | [confidentiality] | confidentiality |
../data/rfc/rfc2975.txt- | | | [data object sec.]|
../data/rfc/rfc2975.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
../data/rfc/rfc2975.txt- | | Archival | Archival |
../data/rfc/rfc2975.txt: | Usage | accounting | accounting |
../data/rfc/rfc2975.txt- | Sensitive | Integrity, | Integrity, |
../data/rfc/rfc2975.txt- | Billing, | authentication, | authentication, |
../data/rfc/rfc2975.txt- | Cost | replay protection | replay prot. |
../data/rfc/rfc2975.txt- | Allocation & | [confidentiality] | confidentiality |
../data/rfc/rfc2975.txt- | Auditing | [Bounds on | [data object sec.]|
../data/rfc/rfc2975.txt- | | processing delay] | [Bounds on |
../data/rfc/rfc2975.txt- | | | processing delay] |
../data/rfc/rfc2975.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
../data/rfc/rfc2975.txt- | | Archival | Archival |
../data/rfc/rfc2975.txt: | Time | accounting | accounting |
../data/rfc/rfc2975.txt- | Sensitive | Integrity, | Integrity, |
../data/rfc/rfc2975.txt- | Billing, | authentication, | authentication, |
../data/rfc/rfc2975.txt- | fraud | replay protection | replay prot. |
../data/rfc/rfc2975.txt- | detection, | [confidentiality] | confidentiality |
../data/rfc/rfc2975.txt- | roaming | | [Data object |
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 13]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-2. Scaling and reliability
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- With the continuing growth of the Internet, it is important that
../data/rfc/rfc2975.txt: accounting management systems be scalable and reliable. This section
../data/rfc/rfc2975.txt: discusses the resources consumed by accounting management systems as
../data/rfc/rfc2975.txt- well as the scalability and reliability properties exhibited by
../data/rfc/rfc2975.txt- various data collection and transport models.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-2.1. Fault resilience
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- As noted earlier, in applications such as usage-sensitive billing,
../data/rfc/rfc2975.txt: cost allocation and auditing, an archival approach to accounting is
../data/rfc/rfc2975.txt- frequently mandated, due to financial and legal requirements. Since
../data/rfc/rfc2975.txt: in such situations loss of accounting data can translate to revenue
../data/rfc/rfc2975.txt- loss, there is incentive to engineer a high degree of fault
../data/rfc/rfc2975.txt- resilience. Faults which may be encountered include:
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Packet loss
../data/rfc/rfc2975.txt: Accounting server failures
../data/rfc/rfc2975.txt- Network failures
../data/rfc/rfc2975.txt- Device reboots
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: To date, much of the debate on accounting reliability has focused on
../data/rfc/rfc2975.txt- resilience against packet loss and the differences between UDP, SCTP
../data/rfc/rfc2975.txt- and TCP-based transport. However, it should be understood that
../data/rfc/rfc2975.txt- resilience against packet loss is only one aspect of meeting
../data/rfc/rfc2975.txt: archival accounting requirements.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- As noted in [18], "once the cable is cut you don't need more
../data/rfc/rfc2975.txt- retransmissions, you need a *lot* more voltage." Thus, the choice of
../data/rfc/rfc2975.txt- transport has no impact on resilience against faults such as network
../data/rfc/rfc2975.txt: partition, accounting server failures or device reboots. What does
../data/rfc/rfc2975.txt- provide resilience against these faults is non-volatile storage.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- The importance of non-volatile storage in design of reliable
../data/rfc/rfc2975.txt: accounting systems cannot be over-emphasized. Without non-volatile
../data/rfc/rfc2975.txt- storage, event-driven systems will lose data once the transmission
../data/rfc/rfc2975.txt- timeout has been exceeded, and batching designs will experience data
../data/rfc/rfc2975.txt: loss once the internal memory used for accounting data storage has
../data/rfc/rfc2975.txt- been exceeded. Via use of non-volatile storage, and internally
../data/rfc/rfc2975.txt- stored interim records, most of these data losses can be avoided.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- It may even be argued that non-volatile storage is more important to
../data/rfc/rfc2975.txt: accounting reliability than network connectivity, since for many
../data/rfc/rfc2975.txt: years reliable accounting systems were implemented based solely on
../data/rfc/rfc2975.txt- physical storage, without any network connectivity. For example,
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 14]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- phone usage data used to be stored on paper, film, or magnetic media
../data/rfc/rfc2975.txt- and carried from the place of collection to a central location for
../data/rfc/rfc2975.txt- bill processing.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:2.1.1. Interim accounting
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Interim accounting provides protection against loss of session
../data/rfc/rfc2975.txt- summary data by providing checkpoint information that can be used to
../data/rfc/rfc2975.txt- reconstruct the session record in the event that the session summary
../data/rfc/rfc2975.txt- information is lost. This technique may be applied to any data
../data/rfc/rfc2975.txt- collection model (i.e. event-driven or polling) and is supported in
../data/rfc/rfc2975.txt- both RADIUS [25] and in TACACS+.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: While interim accounting can provide resilience against packet loss,
../data/rfc/rfc2975.txt- server failures, short-duration network failures, or device reboot,
../data/rfc/rfc2975.txt: its applicability is limited. Transmission of interim accounting
../data/rfc/rfc2975.txt- data over the wire should not be thought of as a mainstream
../data/rfc/rfc2975.txt- reliability improvement technique since it increases use of network
../data/rfc/rfc2975.txt- bandwidth in normal operation, while providing benefits only in the
../data/rfc/rfc2975.txt- event of a fault.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Since most packet loss on the Internet is due to congestion, sending
../data/rfc/rfc2975.txt: interim accounting data over the wire can make the problem worse by
../data/rfc/rfc2975.txt: increasing bandwidth usage. Therefore on-the-wire interim accounting
../data/rfc/rfc2975.txt: is best restricted to high-value accounting data such as information
../data/rfc/rfc2975.txt- on long-lived sessions. To protect against loss of data on such
../data/rfc/rfc2975.txt- sessions, the interim reporting interval is typically set several
../data/rfc/rfc2975.txt- standard deviations larger than the average session duration. This
../data/rfc/rfc2975.txt- ensures that most sessions will not result in generation of interim
../data/rfc/rfc2975.txt: accounting events and the additional bandwidth consumed by interim
../data/rfc/rfc2975.txt: accounting will be limited. However, as the interim accounting
../data/rfc/rfc2975.txt- interval decreases toward the average session time, the additional
../data/rfc/rfc2975.txt: bandwidth consumed by interim accounting increases markedly, and as a
../data/rfc/rfc2975.txt- result, the interval must be set with caution.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Where non-volatile storage is unavailable, interim accounting can
../data/rfc/rfc2975.txt- also result in excessive consumption of memory that could be better
../data/rfc/rfc2975.txt- allocated to storage of session data. As a result, implementors
../data/rfc/rfc2975.txt: should be careful to ensure that new interim accounting data
../data/rfc/rfc2975.txt- overwrites previous data rather than accumulating additional interim
../data/rfc/rfc2975.txt- records in memory, thereby worsening the buffer exhaustion problem.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Given the increasing popularity of non-volatile storage for use in
../data/rfc/rfc2975.txt- consumer devices such as digital cameras, such devices are rapidly
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 15]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Where non-volatile storage is available, this can be used to store
../data/rfc/rfc2975.txt: interim accounting data. Stored interim events are then replaced by
../data/rfc/rfc2975.txt- updated interim events or by session data when the session completes.
../data/rfc/rfc2975.txt- The session data can itself be erased once the data has been
../data/rfc/rfc2975.txt- transmitted and acknowledged at the application layer. This approach
../data/rfc/rfc2975.txt- avoids interim data being transmitted over the wire except in the
../data/rfc/rfc2975.txt- case of a device reboot. When a device reboots, internally stored
../data/rfc/rfc2975.txt: interim records are transferred to the accounting server.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-2.1.2. Multiple record sessions
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Generation of multiple accounting records within a session can
../data/rfc/rfc2975.txt- introduce scalability problems that cannot be controlled using the
../data/rfc/rfc2975.txt: techniques available in interim accounting.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- For example, in the case of interim records kept in non-volatile
../data/rfc/rfc2975.txt- storage, it is possible to overwrite previous interim records with
../data/rfc/rfc2975.txt- the most recent one or summarize them to a session record. Where
../data/rfc/rfc2975.txt- interim updates are sent over the wire, it is possible to control
../data/rfc/rfc2975.txt: bandwidth usage by adjusting the interim accounting interval.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- These measures are not applicable where multiple session records are
../data/rfc/rfc2975.txt- produced from a single session, since these records cannot be
../data/rfc/rfc2975.txt- summarized or overwritten without loss of information. As a result,
../data/rfc/rfc2975.txt- multiple record production can result in increased consumption of
--
../data/rfc/rfc2975.txt- implemented carelessly, create a sudden peak in the consumption of
../data/rfc/rfc2975.txt- memory and bandwidth as the records need to be stored and/or
../data/rfc/rfc2975.txt- transported. Rather than attempting to send all of the records at
../data/rfc/rfc2975.txt- once, it may be desirable to keep them in non-volatile storage and
../data/rfc/rfc2975.txt- send all of the related records together in a batch when the session
../data/rfc/rfc2975.txt: completes. It may also be desirable to shape the accounting traffic
../data/rfc/rfc2975.txt- flow so as to reduce the peak bandwidth consumption. This can be
../data/rfc/rfc2975.txt- accomplished by introduction of a randomized delay interval. If the
../data/rfc/rfc2975.txt: home domain can also control the generation of multiple accounting
../data/rfc/rfc2975.txt- records, the estimation of the worst-case processing requirements can
../data/rfc/rfc2975.txt- be very difficult.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-2.1.3. Packet loss
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: As packet loss is a fact of life on the Internet, accounting
../data/rfc/rfc2975.txt- protocols dealing with session data need to be resilient against
../data/rfc/rfc2975.txt- packet loss. This is particularly important in inter-domain
../data/rfc/rfc2975.txt: accounting, where packets often pass through Network Access Points
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 16]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- (NAPs) where packet loss may be substantial. Resilience against
../data/rfc/rfc2975.txt- packet loss can be accomplished via implementation of a retry
../data/rfc/rfc2975.txt- mechanism on top of UDP, or use of TCP [7] or SCTP [26]. On-the-wire
../data/rfc/rfc2975.txt: interim accounting provides only limited benefits in mitigating the
../data/rfc/rfc2975.txt- effects of packet loss.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: UDP-based transport is frequently used in accounting applications.
../data/rfc/rfc2975.txt: However, this is not appropriate in all cases. Where accounting data
../data/rfc/rfc2975.txt- will not fit within a single UDP packet without fragmentation, use of
../data/rfc/rfc2975.txt- TCP or SCTP transport may be preferred to use of multiple round-trips
../data/rfc/rfc2975.txt- in UDP. As noted in [47] and [49], this may be an issue in the
../data/rfc/rfc2975.txt- retrieval of large tables.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- In addition, in cases where congestion is likely, such as in inter-
../data/rfc/rfc2975.txt: domain accounting, TCP or SCTP congestion control and round-trip time
../data/rfc/rfc2975.txt- estimation will be very useful, optimizing throughput. In
../data/rfc/rfc2975.txt- applications which require maintenance of session state, such as
../data/rfc/rfc2975.txt- simultaneous usage control, TCP and application-layer keep alive
../data/rfc/rfc2975.txt- packets or SCTP with its built-in heartbeat capabilities provide a
../data/rfc/rfc2975.txt- mechanism for keeping track of session state.
--
../data/rfc/rfc2975.txt- Data model
../data/rfc/rfc2975.txt- Retry behavior
../data/rfc/rfc2975.txt- Congestion control
../data/rfc/rfc2975.txt- Timeout behavior
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Accounting reliability can be influenced by how the data is modeled.
../data/rfc/rfc2975.txt- For example, it is almost always preferable to use cumulative
../data/rfc/rfc2975.txt: variables rather than expressing accounting data in terms of a change
../data/rfc/rfc2975.txt- from a previous data item. With cumulative data, the current state
../data/rfc/rfc2975.txt- can be recovered by a successful retrieval, even after many packets
../data/rfc/rfc2975.txt- have been lost. However, if the data is transmitted as a change then
../data/rfc/rfc2975.txt- the state will not be recovered until the next cumulative update is
../data/rfc/rfc2975.txt- sent. Thus, such implementations are much more vulnerable to packet
../data/rfc/rfc2975.txt- loss, and should be avoided wherever possible.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- In designing a UDP retry mechanism, it is important that the retry
../data/rfc/rfc2975.txt- timers relate to the round-trip time, so that retransmissions will
../data/rfc/rfc2975.txt- not typically occur within the period in which acknowledgments may be
../data/rfc/rfc2975.txt: expected to arrive. Accounting bandwidth may be significant in some
../data/rfc/rfc2975.txt- circumstances, so that the added traffic due to unnecessary
../data/rfc/rfc2975.txt- retransmissions may increase congestion levels.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 17]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Congestion control in accounting data transfer is a somewhat
../data/rfc/rfc2975.txt: controversial issue. Since accounting traffic is often considered
../data/rfc/rfc2975.txt- mission-critical, it has been argued that congestion control is not a
../data/rfc/rfc2975.txt- requirement; better to let other less-critical traffic back off in
../data/rfc/rfc2975.txt- response to congestion. Moreover, without non-volatile storage,
../data/rfc/rfc2975.txt: congestive back-off in accounting applications can result in data
../data/rfc/rfc2975.txt- loss due to buffer exhaustion.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: However, it can also be argued that in modern accounting
../data/rfc/rfc2975.txt- implementations, it is possible to implement congestion control while
../data/rfc/rfc2975.txt- improving throughput and maintaining high reliability. In
../data/rfc/rfc2975.txt- circumstances where there is sustained packet loss, there simply is
../data/rfc/rfc2975.txt- not sufficient capacity to maintain existing transmission rates.
../data/rfc/rfc2975.txt- Thus, aggregate throughput will actually improve if congestive back-
../data/rfc/rfc2975.txt- off is implemented. This is due to elimination of retransmissions
../data/rfc/rfc2975.txt- and the ability to utilize techniques such as RED to desynchronize
../data/rfc/rfc2975.txt- flows. In addition, with QoS mechanisms such as differentiated
../data/rfc/rfc2975.txt: services, it is possible to mark accounting packets for preferential
../data/rfc/rfc2975.txt- handling so as to provide for lower packet loss if desired. Thus
../data/rfc/rfc2975.txt- considerable leeway is available to the network administrator in
../data/rfc/rfc2975.txt: controlling the treatment of accounting packets and hard coding
../data/rfc/rfc2975.txt- inelastic behavior is unnecessary. Typically, systems implementing
../data/rfc/rfc2975.txt: non-volatile storage allow for backlogged accounting data to be
../data/rfc/rfc2975.txt- placed in non-volatile storage pending transmission, so that buffer
../data/rfc/rfc2975.txt- exhaustion resulting from congestive back-off need not be a concern.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Since UDP is not really a transport protocol, UDP-based accounting
../data/rfc/rfc2975.txt- protocols such as [4] often do not prescribe timeout behavior. Thus
../data/rfc/rfc2975.txt- implementations may exhibit widely different behavior. For example,
../data/rfc/rfc2975.txt: one implementation may drop accounting data after three constant
../data/rfc/rfc2975.txt- duration retries to the same server, while another may implement
../data/rfc/rfc2975.txt- exponential back-off to a given server, then switch to another
../data/rfc/rfc2975.txt- server, up to a total timeout interval of twelve hours, while storing
../data/rfc/rfc2975.txt- the untransmitted data on non-volatile storage. The practical
../data/rfc/rfc2975.txt- difference between these approaches is substantial; the former
../data/rfc/rfc2975.txt: approach will not satisfy archival accounting requirements while the
../data/rfc/rfc2975.txt- latter may. More predictable behavior can be achieved via use of
../data/rfc/rfc2975.txt- SCTP or TCP transport.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:2.1.4. Accounting server failover
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: In the event of a failure of the primary accounting server, it is
../data/rfc/rfc2975.txt- desirable for the device to failover to a secondary server.
../data/rfc/rfc2975.txt- Providing one or more secondary servers can remove much of the risk
../data/rfc/rfc2975.txt: of accounting server failure, and as a result use of secondary
../data/rfc/rfc2975.txt- servers has become commonplace.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 18]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- For protocols based on TCP, it is possible for the device to maintain
../data/rfc/rfc2975.txt: connections to both the primary and secondary accounting servers,
../data/rfc/rfc2975.txt- using the secondary connection after expiration of a timer on the
../data/rfc/rfc2975.txt- primary connection. Alternatively, it is possible to open a
../data/rfc/rfc2975.txt: connection to the secondary accounting server after a timeout or loss
../data/rfc/rfc2975.txt- of the primary connection, or on expiration of a timer. Thus,
../data/rfc/rfc2975.txt: accounting protocols based on TCP are capable of responding more
../data/rfc/rfc2975.txt- rapidly to connectivity failures than TCP timeouts would otherwise
../data/rfc/rfc2975.txt- allow, at the expense of an increased risk of duplicates.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- With SCTP, it is possible to control transport layer timeout
../data/rfc/rfc2975.txt: behavior, and therefore it is not necessary for the accounting
../data/rfc/rfc2975.txt- application to maintain its own timers. SCTP also enables
../data/rfc/rfc2975.txt- multiplexing of multiple connections within a single transport
../data/rfc/rfc2975.txt- connection, all maintaining the same congestion control state,
../data/rfc/rfc2975.txt- avoiding the "head of line blocking" issues that can occur with TCP.
../data/rfc/rfc2975.txt- However, since SCTP is not widely available, use of this transport
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- For protocols using UDP, transmission to the secondary server can
../data/rfc/rfc2975.txt- occur after a number of retries or timer expiration. For
../data/rfc/rfc2975.txt- compatibility with congestion avoidance, it is advisable to
../data/rfc/rfc2975.txt- incorporate techniques such as round-trip-time estimation, slow start
../data/rfc/rfc2975.txt: and congestive back-off. Thus the accounting protocol designer
../data/rfc/rfc2975.txt- utilizing UDP often is lead to re-inventing techniques already
../data/rfc/rfc2975.txt- existing in TCP and SCTP. As a result, the use of raw UDP transport
../data/rfc/rfc2975.txt: in accounting applications is not recommended.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- With any transport it is possible for the primary and secondary
../data/rfc/rfc2975.txt: accounting servers to receive duplicate packets, so support for
../data/rfc/rfc2975.txt: duplicate elimination is required. Since accounting server failures
../data/rfc/rfc2975.txt: can result in data accumulation on accounting clients, use of non-
../data/rfc/rfc2975.txt- volatile storage can ensure against data loss due to transmission
../data/rfc/rfc2975.txt: timeouts or buffer exhaustion. On-the-wire interim accounting
../data/rfc/rfc2975.txt- provides only limited benefits in mitigating the effects of
../data/rfc/rfc2975.txt: accounting server failures.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-2.1.5. Application layer acknowledgments
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: It is possible for the accounting server to experience partial
../data/rfc/rfc2975.txt- failures. For example, a failure in the database back end could
../data/rfc/rfc2975.txt: leave the accounting retrieval process or thread operable while the
../data/rfc/rfc2975.txt- process or thread responsible for storing the data is non-functional.
../data/rfc/rfc2975.txt: Similarly, it is possible for the accounting application to run out
../data/rfc/rfc2975.txt- of disk space, making it unable to continue storing incoming session
../data/rfc/rfc2975.txt- records.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 19]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- In such cases it is desirable to distinguish between transport layer
../data/rfc/rfc2975.txt- acknowledgment and application layer acknowledgment. Even though
../data/rfc/rfc2975.txt- both acknowledgments may be sent within the same packet (such as a
--
../data/rfc/rfc2975.txt- layer to acknowledge receipt via transport layer acknowledgment,
../data/rfc/rfc2975.txt- without having delivered the data to the application. Similarly, the
../data/rfc/rfc2975.txt- application may not complete the tasks necessary to take
../data/rfc/rfc2975.txt- responsibility for the data.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: For example, an accounting server may receive data from the transport
../data/rfc/rfc2975.txt- layer but be incapable of storing it data due to a back end database
../data/rfc/rfc2975.txt- problem or disk fault. In this case it should not send an
../data/rfc/rfc2975.txt- application layer acknowledgment, even though a a transport layer
../data/rfc/rfc2975.txt- acknowledgment is appropriate. Rather, an application layer error
../data/rfc/rfc2975.txt- message should be sent indicating the source of the problem, such as
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 20]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-2.1.6. Network failures
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Network failures may result in partial or complete loss of
../data/rfc/rfc2975.txt: connectivity for the accounting client. In the event of partial
../data/rfc/rfc2975.txt- connectivity loss, it may not be possible to reach the primary
../data/rfc/rfc2975.txt: accounting server, in which case switch over to the secondary
../data/rfc/rfc2975.txt: accounting server is necessary. In the event of a network partition,
../data/rfc/rfc2975.txt: it may be necessary to store accounting events in device memory or
../data/rfc/rfc2975.txt- non-volatile storage until connectivity can be re-established.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: As with accounting server failures, on-the-wire interim accounting
../data/rfc/rfc2975.txt- provides only limited benefits in mitigating the effects of network
../data/rfc/rfc2975.txt- failures.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-2.1.7. Device reboots
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- In the event of a device reboot, it is desirable to minimize the loss
../data/rfc/rfc2975.txt- of data on sessions in progress. Such losses may be significant even
../data/rfc/rfc2975.txt- if the devices themselves are very reliable, due to long-lived
../data/rfc/rfc2975.txt- sessions, which can comprise a significant fraction of total resource
../data/rfc/rfc2975.txt- consumption. To guard against loss of these high-value sessions,
../data/rfc/rfc2975.txt: interim accounting data is typically transmitted over the wire. When
../data/rfc/rfc2975.txt: interim accounting in-place is combined with non-volatile storage it
../data/rfc/rfc2975.txt- becomes possible to guard against data loss in much shorter sessions.
../data/rfc/rfc2975.txt: This is possible since interim accounting data need only be stored in
../data/rfc/rfc2975.txt- non-volatile memory until the session completes, at which time the
../data/rfc/rfc2975.txt- interim data may be replaced by the session record. As a result,
../data/rfc/rfc2975.txt: interim accounting data need never be sent over the wire, and it is
../data/rfc/rfc2975.txt- possible to decrease the interim interval so as to provide a very
../data/rfc/rfc2975.txt- high degree of protection against data loss.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:2.1.8. Accounting proxies
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- In order to maintain high reliability, it is important that
../data/rfc/rfc2975.txt: accounting proxies pass through transport and application layer
../data/rfc/rfc2975.txt: acknowledgments and do not store and forward accounting packets.
../data/rfc/rfc2975.txt- This enables the end-systems to control re-transmission behavior and
../data/rfc/rfc2975.txt- utilize techniques such as non-volatile storage and secondary servers
../data/rfc/rfc2975.txt- to improve resilience.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Accounting proxies sending a transport or application layer ACK to
../data/rfc/rfc2975.txt: the device without receiving one from the accounting server fool the
../data/rfc/rfc2975.txt: device into thinking that the accounting request had been accepted by
../data/rfc/rfc2975.txt: the accounting server when this is not the case. As a result, the
../data/rfc/rfc2975.txt: device can delete the accounting packet from non-volatile storage
../data/rfc/rfc2975.txt: before it has been accepted by the accounting server. The leaves the
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 21]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: accounting proxy responsible for delivering accounting packets. If
../data/rfc/rfc2975.txt: the accounting proxy involves moving parts (e.g. a disk drive) while
../data/rfc/rfc2975.txt- the devices do not, overall system reliability can be reduced.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Store and forward accounting proxies only add value in situations
../data/rfc/rfc2975.txt: where the accounting subsystem is unreliable. For example, where
../data/rfc/rfc2975.txt: devices do not implement non-volatile storage and the accounting
../data/rfc/rfc2975.txt- protocol lacks transport and application layer reliability, locating
../data/rfc/rfc2975.txt: the accounting proxy (with its stable storage) close to the device
../data/rfc/rfc2975.txt- can reduce the risk of data loss.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- However, such systems are inherently unreliable so that they are only
../data/rfc/rfc2975.txt- appropriate for use in capacity planning or non-usage sensitive
../data/rfc/rfc2975.txt: billing applications. If archival accounting reliability is desired,
../data/rfc/rfc2975.txt: it is necessary to engineer a reliable accounting system from the
../data/rfc/rfc2975.txt- start using the techniques described in this document, rather than
../data/rfc/rfc2975.txt- attempting to patch an inherently unreliable system by adding store
../data/rfc/rfc2975.txt: and forward accounting proxies.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 22]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-2.1.9. Fault resilience summary
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--
../data/rfc/rfc2975.txt- | | |
../data/rfc/rfc2975.txt- | Packet | Retransmission based on RTT |
../data/rfc/rfc2975.txt- | loss | Congestion control |
../data/rfc/rfc2975.txt- | | Well-defined timeout behavior |
../data/rfc/rfc2975.txt- | | Duplicate elimination |
../data/rfc/rfc2975.txt: | | Interim accounting* |
../data/rfc/rfc2975.txt- | | Non-volatile storage |
../data/rfc/rfc2975.txt- | | Cumulative variables |
../data/rfc/rfc2975.txt- | | |
../data/rfc/rfc2975.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
../data/rfc/rfc2975.txt- | | |
../data/rfc/rfc2975.txt: | Accounting | Primary-secondary servers |
../data/rfc/rfc2975.txt- | server & net | Duplicate elimination |
../data/rfc/rfc2975.txt: | failures | Interim accounting* |
../data/rfc/rfc2975.txt- | | Application layer ACK & error msgs. |
../data/rfc/rfc2975.txt- | | Non-volatile storage |
../data/rfc/rfc2975.txt- | | |
../data/rfc/rfc2975.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
../data/rfc/rfc2975.txt- | | |
../data/rfc/rfc2975.txt: | Device | Interim accounting* |
../data/rfc/rfc2975.txt- | reboots | Non-volatile storage |
../data/rfc/rfc2975.txt- | | |
../data/rfc/rfc2975.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Key
../data/rfc/rfc2975.txt- * = limited usefulness without non-volatile storage
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Note: Accounting proxies are not a reliability
../data/rfc/rfc2975.txt- enhancement mechanism.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-2.2. Resource consumption
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- In the process of growing to meet the needs of providers and
../data/rfc/rfc2975.txt: customers, accounting management systems consume a variety of
../data/rfc/rfc2975.txt- resources, including:
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Network bandwidth
../data/rfc/rfc2975.txt- Memory
../data/rfc/rfc2975.txt- Non-volatile storage
../data/rfc/rfc2975.txt: State on the accounting management system
../data/rfc/rfc2975.txt- CPU on the management system and managed devices
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 23]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- In order to understand the limits to scaling, we examine each of
../data/rfc/rfc2975.txt- these resources in turn.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-2.2.1. Network bandwidth
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Accounting management systems consume network bandwidth in
../data/rfc/rfc2975.txt: transferring accounting data. The network bandwidth consumed is
../data/rfc/rfc2975.txt- proportional to the amount of data transferred, as well as required
../data/rfc/rfc2975.txt: network overhead. Since accounting data for a given event may be 100
../data/rfc/rfc2975.txt- octets or less, if each event is transferred individually, overhead
../data/rfc/rfc2975.txt- can represent a considerable proportion of total bandwidth
../data/rfc/rfc2975.txt- consumption. As a result, it is often desirable to transfer
../data/rfc/rfc2975.txt: accounting data in batches, enabling network overhead to be spread
../data/rfc/rfc2975.txt- over a larger payload, and enabling efficient use of compression. As
../data/rfc/rfc2975.txt: noted in [48], compression can be enabled in the accounting protocol,
../data/rfc/rfc2975.txt- or can be done at the IP layer as described in [5].
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-2.2.2. Memory
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: In accounting systems without non-volatile storage, accounting data
../data/rfc/rfc2975.txt- must be stored in volatile memory during the period between when it
../data/rfc/rfc2975.txt- is generated and when it is transferred. The resulting memory
../data/rfc/rfc2975.txt- consumption will depend on retry and retransmission algorithms.
../data/rfc/rfc2975.txt- Since systems designed for high reliability will typically wish to
../data/rfc/rfc2975.txt: retry for long periods, or may store interim accounting data, the
../data/rfc/rfc2975.txt- resulting memory consumption can be considerable. As a result, if
../data/rfc/rfc2975.txt- non-volatile storage is unavailable, it may be desirable to compress
../data/rfc/rfc2975.txt: accounting data awaiting transmission.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: As noted earlier, implementors of interim accounting should take care
../data/rfc/rfc2975.txt- to ensure against excessive memory usage by overwriting older interim
../data/rfc/rfc2975.txt: accounting data with newer data for the same session rather than
../data/rfc/rfc2975.txt- accumulating interim data in the buffer.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-2.2.3. Non-volatile storage
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Since accounting data stored in memory will typically be lost in the
../data/rfc/rfc2975.txt- event of a device reboot or a timeout, it may be desirable to provide
../data/rfc/rfc2975.txt: non-volatile storage for undelivered accounting data. With the costs
../data/rfc/rfc2975.txt- of non-volatile storage declining rapidly, network devices will be
../data/rfc/rfc2975.txt- increasingly capable of incorporating non-volatile storage support
../data/rfc/rfc2975.txt- over the next few years.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Non-volatile storage may be used to store interim or session records.
../data/rfc/rfc2975.txt: As with memory utilization, interim accounting overwrite is desirable
../data/rfc/rfc2975.txt- so as to prevent excessive storage consumption. Note that the use of
../data/rfc/rfc2975.txt- ASCII data representation enables use of highly efficient text
../data/rfc/rfc2975.txt- compression algorithms that can minimize storage requirements. Such
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 24]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- compression algorithms are only typically applied to session records
../data/rfc/rfc2975.txt- so as to enable implementation of interim data overwrite.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:2.2.4. State on the accounting management system
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: In order to keep track of received accounting data, accounting
../data/rfc/rfc2975.txt- management systems may need to keep state on managed devices or
../data/rfc/rfc2975.txt- concurrent sessions. Since the number of devices is typically much
../data/rfc/rfc2975.txt- smaller than the number of concurrent sessions, it is desirable to
../data/rfc/rfc2975.txt- keep only per-device state if possible.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-2.2.5. CPU requirements
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- CPU consumption of the managed and managing nodes will be
../data/rfc/rfc2975.txt: proportional to the complexity of the required accounting processing.
../data/rfc/rfc2975.txt- Operations such as ASN.1 encoding and decoding,
../data/rfc/rfc2975.txt- compression/decompression, and encryption/decryption can consume
../data/rfc/rfc2975.txt: considerable resources, both on accounting clients and servers.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: The effect of these operations on accounting system reliability
../data/rfc/rfc2975.txt- should not be under-estimated, particularly in the case of devices
../data/rfc/rfc2975.txt- with moderate CPU resources. In the event that devices are over-
../data/rfc/rfc2975.txt: taxed by accounting tasks, it is likely that overall device
../data/rfc/rfc2975.txt- reliability will suffer.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 25]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-2.2.6. Efficiency measures
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--
../data/rfc/rfc2975.txt- | Bandwidth | Compression |
../data/rfc/rfc2975.txt- | | |
../data/rfc/rfc2975.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
../data/rfc/rfc2975.txt- | | |
../data/rfc/rfc2975.txt- | Memory | Compression |
../data/rfc/rfc2975.txt: | | Interim accounting overwrite |
../data/rfc/rfc2975.txt- | | |
../data/rfc/rfc2975.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
../data/rfc/rfc2975.txt- | | |
../data/rfc/rfc2975.txt- | Non-volatile | Compression |
../data/rfc/rfc2975.txt: | Storage | Interim accounting overwrite |
../data/rfc/rfc2975.txt- | | |
../data/rfc/rfc2975.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
../data/rfc/rfc2975.txt- | | |
../data/rfc/rfc2975.txt- | System | Per-device state |
../data/rfc/rfc2975.txt- | state | |
--
../data/rfc/rfc2975.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-2.3. Data collection models
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Several data collection models are currently in use today for the
../data/rfc/rfc2975.txt: purposes of accounting data collection. These include:
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Polling model
../data/rfc/rfc2975.txt- Event-driven model without batching
../data/rfc/rfc2975.txt- Event-driven model with batching
../data/rfc/rfc2975.txt- Event-driven polling model
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 26]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-2.3.1. Polling model
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: In the polling model, an accounting manager will poll devices for
../data/rfc/rfc2975.txt: accounting information at regular intervals. In order to ensure
../data/rfc/rfc2975.txt- against loss of data, the polling interval will need to be shorter
../data/rfc/rfc2975.txt: than the maximum time that accounting data can be stored on the
../data/rfc/rfc2975.txt- polled device. For devices without non-volatile stage, this is
../data/rfc/rfc2975.txt- typically determined by available memory; for devices with non-
../data/rfc/rfc2975.txt- volatile storage the maximum polling interval is determined by the
../data/rfc/rfc2975.txt- size of non-volatile storage.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- The polling model results in an accumulation of data within
../data/rfc/rfc2975.txt- individual devices, and as a result, data is typically transferred to
../data/rfc/rfc2975.txt: the accounting manager in a batch, resulting in an efficient transfer
../data/rfc/rfc2975.txt: process. In terms of Accounting Manager state, polling systems scale
../data/rfc/rfc2975.txt- with the number of managed devices, and system bandwidth usage scales
../data/rfc/rfc2975.txt- with the amount of data transferred.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Without non-volatile storage, the polling model results in loss of
../data/rfc/rfc2975.txt: accounting data due to device reboots, but not due to packet loss or
../data/rfc/rfc2975.txt- network failures of sufficiently short duration to be handled within
../data/rfc/rfc2975.txt: available memory. This is because the Accounting Manager will
../data/rfc/rfc2975.txt- continue to poll until the data is received. In situations where
../data/rfc/rfc2975.txt: operational difficulties are encountered, the volume of accounting
../data/rfc/rfc2975.txt- data will frequently increase so as to make data loss more likely.
../data/rfc/rfc2975.txt- However, in this case the polling model will detect the problem since
../data/rfc/rfc2975.txt- attempts to reach the managed devices will fail.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- The polling model scales poorly for implementation of shared use or
../data/rfc/rfc2975.txt- roaming services, including wireless data, Internet telephony, QoS
../data/rfc/rfc2975.txt- provisioning or Internet access. This is because in order to
../data/rfc/rfc2975.txt: retrieve accounting data for users within a given domain, the
../data/rfc/rfc2975.txt: Accounting Management station would need to periodically poll all
../data/rfc/rfc2975.txt- devices in all domains, most of which would not contain any relevant
../data/rfc/rfc2975.txt- data. There are also issues with processing delay, since use of a
../data/rfc/rfc2975.txt- polling interval also implies an average processing delay of half the
../data/rfc/rfc2975.txt: polling interval. This may be too high for accounting data that
../data/rfc/rfc2975.txt- requires low processing delay. Thus the event-driven polling or the
../data/rfc/rfc2975.txt- pure event-driven approach is more appropriate for usage sensitive
../data/rfc/rfc2975.txt- billing applications such as shared use or roaming implementations.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Per-device state is typical of polling-based network management
../data/rfc/rfc2975.txt: systems, which often also carry out accounting management functions,
../data/rfc/rfc2975.txt- since network management systems need to keep track of the state of
../data/rfc/rfc2975.txt- network devices for operational purposes. These systems offer
../data/rfc/rfc2975.txt- average processing delays equal to half the polling interval.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 27]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-2.3.2. Event-driven model without batching
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: In the event-driven model, a device will contact the accounting
../data/rfc/rfc2975.txt: server or manager when it is ready to transfer accounting data. Most
../data/rfc/rfc2975.txt: event-driven accounting systems, such as those based on RADIUS
../data/rfc/rfc2975.txt: accounting, described in [4], transfer only one accounting event per
../data/rfc/rfc2975.txt- packet, which is inefficient.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Without non-volatile storage, a pure event-driven model typically
../data/rfc/rfc2975.txt: stores accounting events that have not yet been delivered only until
../data/rfc/rfc2975.txt- the timeout interval expires. As a result this model has the
../data/rfc/rfc2975.txt- smallest memory requirements. Once the timeout interval has expired,
../data/rfc/rfc2975.txt: the accounting event is lost, even if the device has sufficient
../data/rfc/rfc2975.txt- buffer space to continue to store it. As a result, the event-driven
../data/rfc/rfc2975.txt: model is the least reliable, since accounting data loss will occur
../data/rfc/rfc2975.txt- due to device reboots, sustained packet loss, or network failures of
../data/rfc/rfc2975.txt- duration greater than the timeout interval. In event-driven
../data/rfc/rfc2975.txt: protocols without a "keep alive" message, accounting servers cannot
../data/rfc/rfc2975.txt- assume a device failure should no messages arrive for an extended
../data/rfc/rfc2975.txt: period. Thus, event-driven accounting systems are typically not
../data/rfc/rfc2975.txt- useful in monitoring of device health.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- The event-driven model is frequently used in shared use networks and
../data/rfc/rfc2975.txt- roaming, since this model sends data to the recipient domains without
../data/rfc/rfc2975.txt- requiring them to poll a large number of devices, most of which have
../data/rfc/rfc2975.txt- no relevant data. Since the event-driven model typically does not
../data/rfc/rfc2975.txt: support batching, it permits accounting records to be sent with low
../data/rfc/rfc2975.txt- processing delay, enabling application of fraud prevention
../data/rfc/rfc2975.txt: techniques. However, because roaming accounting events are
../data/rfc/rfc2975.txt- frequently of high value, the poor reliability of this model is an
../data/rfc/rfc2975.txt- issue. As a result, the event-driven polling model may be more
../data/rfc/rfc2975.txt- appropriate.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Per-session state is typical of event-driven systems without
--
../data/rfc/rfc2975.txt- transfer.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-2.3.3. Event-driven model with batching
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- In the event-driven model with batching, a device will contact the
../data/rfc/rfc2975.txt: accounting server or manager when it is ready to transfer accounting
../data/rfc/rfc2975.txt- data. The device can contact the server when a batch of a given size
../data/rfc/rfc2975.txt- has been gathered, when data of a certain type is available or after
../data/rfc/rfc2975.txt- a minimum time period has elapsed. Such systems can transfer more
../data/rfc/rfc2975.txt: than one accounting event per packet and are thus more efficient.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 28]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: An event-driven system with batching will store accounting events
../data/rfc/rfc2975.txt- that have not yet been delivered up to the limits of memory. As a
../data/rfc/rfc2975.txt: result, accounting data loss will occur due to device reboots, but
../data/rfc/rfc2975.txt- not due to packet loss or network failures of sufficiently short
../data/rfc/rfc2975.txt- duration to be handled within available memory. Note that while
../data/rfc/rfc2975.txt- transfer efficiency will increase with batch size, without non-
../data/rfc/rfc2975.txt- volatile storage, the potential data loss from a device reboot will
../data/rfc/rfc2975.txt- also increase.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Where event-driven systems with batching have a keep-alive interval
../data/rfc/rfc2975.txt: and run over reliable transport, the accounting server can assume
../data/rfc/rfc2975.txt- that a failure has occurred if no messages are received within the
../data/rfc/rfc2975.txt- keep-alive interval. Thus, such implementations can be useful in
../data/rfc/rfc2975.txt- monitoring of device health. When used for this purpose the average
../data/rfc/rfc2975.txt- time delay prior to failure detection is one half the keep-alive
../data/rfc/rfc2975.txt- interval.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Through implementation of a scheduling algorithm, event-driven
../data/rfc/rfc2975.txt: systems with batching can deliver appropriate service to accounting
../data/rfc/rfc2975.txt- events that require low processing delay. For example, high-value
../data/rfc/rfc2975.txt: inter-domain accounting events could be sent immediately, thus
../data/rfc/rfc2975.txt- enabling use of fraud-prevention techniques, while all other events
../data/rfc/rfc2975.txt- would be batched. However, there is a possibility that an event
../data/rfc/rfc2975.txt- requiring low processing delay will be caught behind a batch transfer
../data/rfc/rfc2975.txt- in progress. Thus the maximum processing delay is proportional to
../data/rfc/rfc2975.txt- the maximum batch size divided by the link speed.
--
../data/rfc/rfc2975.txt- devices. As a result this approach scales better than the pure
../data/rfc/rfc2975.txt- event-driven approach, or even the polling approach, and is
../data/rfc/rfc2975.txt- equivalent in terms of scaling to the event-driven polling approach.
../data/rfc/rfc2975.txt- However, the event-driven batching approach has lower processing
../data/rfc/rfc2975.txt- delay than the event-driven polling approach, since delivery of
../data/rfc/rfc2975.txt: accounting data requires fewer round-trips and events requiring low
../data/rfc/rfc2975.txt- processing delay can be accommodated if a scheduling algorithm is
../data/rfc/rfc2975.txt- employed.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-2.3.4. Event-driven polling model
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: In the event-driven polling model an accounting manager will poll the
../data/rfc/rfc2975.txt: device for accounting data only when it receives an event. The
../data/rfc/rfc2975.txt: accounting client can generate an event when a batch of a given size
../data/rfc/rfc2975.txt- has been gathered, when data of a certain type is available or after
../data/rfc/rfc2975.txt- a minimum time period has elapsed. Note that while transfer
../data/rfc/rfc2975.txt- efficiency will increase with batch size, without non-volatile
../data/rfc/rfc2975.txt- storage, the potential data loss from a device reboot will also
../data/rfc/rfc2975.txt- increase.
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 29]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Without non-volatile storage, an event-driven polling model will lose
../data/rfc/rfc2975.txt- data due to device reboots, but not due to packet loss, or network
../data/rfc/rfc2975.txt- partitions of short-duration. Unless a minimum delivery interval is
../data/rfc/rfc2975.txt- set, event-driven polling systems are not useful in monitoring of
../data/rfc/rfc2975.txt- device health.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- The event-driven polling model can be suitable for use in roaming
../data/rfc/rfc2975.txt: since it permits accounting data to be sent to the roaming partners
../data/rfc/rfc2975.txt: with low processing delay. At the same time non-roaming accounting
../data/rfc/rfc2975.txt- can be handled via more efficient polling techniques, thereby
../data/rfc/rfc2975.txt- providing the best of both worlds.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Where batching can be implemented, the state required in event-driven
../data/rfc/rfc2975.txt- polling can be reduced to scale with the number of active devices.
../data/rfc/rfc2975.txt- If portions of the network vary widely in usage, then this state may
../data/rfc/rfc2975.txt- actually be less than that of the polling approach. Note that
../data/rfc/rfc2975.txt- processing delay in this approach is higher than in event-driven
../data/rfc/rfc2975.txt: accounting with batching since at least two round-trips are required
../data/rfc/rfc2975.txt- to deliver data: one for the event notification, and one for the
../data/rfc/rfc2975.txt- resulting poll.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 30]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-2.3.5. Data collection summary
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 31]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:3. Review of Accounting Protocols
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Accounting systems have been successfully implemented using protocols
../data/rfc/rfc2975.txt- such as RADIUS, TACACS+, and SNMP. This section describes the
../data/rfc/rfc2975.txt- characteristics of each of these protocols.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-3.1. RADIUS
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: RADIUS accounting, described in [4], was developed as an add-on to
../data/rfc/rfc2975.txt- the RADIUS authentication protocol, described in [3]. As a result,
../data/rfc/rfc2975.txt: RADIUS accounting shares the event-driven approach of RADIUS
../data/rfc/rfc2975.txt- authentication, without support for batching or polling. As a
../data/rfc/rfc2975.txt: result, RADIUS accounting scales with the number of accounting events
../data/rfc/rfc2975.txt: instead of the number of devices, and accounting transfers are
../data/rfc/rfc2975.txt- inefficient.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Since RADIUS accounting is based on UDP and timeout and retry
../data/rfc/rfc2975.txt- parameters are not specified, implementations vary widely in their
../data/rfc/rfc2975.txt- approach to reliability, with some implementations retrying until
../data/rfc/rfc2975.txt: delivery or buffer exhaustion, and others losing accounting data
../data/rfc/rfc2975.txt: after a few retries. Since RADIUS accounting does not provide for
../data/rfc/rfc2975.txt- application-layer acknowledgments or error messages, a RADIUS
../data/rfc/rfc2975.txt: Accounting-Response is equivalent to a transport-layer acknowledgment
../data/rfc/rfc2975.txt- and provides no protection against application layer malfunctions.
../data/rfc/rfc2975.txt- Due to the lack of reliability, it is not possible to do simultaneous
../data/rfc/rfc2975.txt: usage control based on RADIUS accounting alone. Typically another
../data/rfc/rfc2975.txt- device data source is required, such as polling of a session MIB or a
../data/rfc/rfc2975.txt- command-line session over telnet.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: RADIUS accounting implementations are vulnerable to packet loss as
../data/rfc/rfc2975.txt- well as application layer failures, network failures and device
../data/rfc/rfc2975.txt: reboots. These deficiencies are magnified in inter-domain accounting
../data/rfc/rfc2975.txt- as is required in roaming ([1],[2]). On the other hand, the event-
../data/rfc/rfc2975.txt: driven approach of RADIUS accounting is useful where low processing
../data/rfc/rfc2975.txt- delay is required, such as credit risk management or fraud detection.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: While RADIUS accounting does provide hop-by-hop authentication and
../data/rfc/rfc2975.txt- integrity protection, and IPSEC can be employed to provide hop-by-hop
../data/rfc/rfc2975.txt- confidentiality, data object security is not supported, and thus
../data/rfc/rfc2975.txt: systems based on RADIUS accounting are not capable of being deployed
../data/rfc/rfc2975.txt- with untrusted proxies, or in situations requiring auditability, as
../data/rfc/rfc2975.txt- noted in [2].
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- While RADIUS does not support compression, IP compression, described
../data/rfc/rfc2975.txt- in [5], can be employed to provide this. While in principle
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 32]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-3.2. TACACS+
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: TACACS+ offers an accounting model with start, stop, and interim
../data/rfc/rfc2975.txt- update messages. Since TACACS+ is based on TCP, implementations are
../data/rfc/rfc2975.txt- typically resilient against packet loss and short-lived network
../data/rfc/rfc2975.txt- partitions, and TACACS+ scales with the number of devices. Since
../data/rfc/rfc2975.txt- TACACS+ runs over TCP, it offers support for both transport layer and
../data/rfc/rfc2975.txt- application layer acknowledgments, and is suitable for simultaneous
../data/rfc/rfc2975.txt: usage control and handling of accounting events that require moderate
../data/rfc/rfc2975.txt- though not the lowest processing delay.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- TACACS+ provides for hop-by-hop authentication and integrity
../data/rfc/rfc2975.txt- protection as well as hop-by-hop confidentiality. Data object
../data/rfc/rfc2975.txt- security is not supported, and therefore systems based on TACACS+
../data/rfc/rfc2975.txt: accounting are not deployable in the presence of untrusted proxies.
../data/rfc/rfc2975.txt- While TACACS+ does not support compression, IP compression, described
../data/rfc/rfc2975.txt- in [5], can be employed to provide this.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-3.3. SNMP
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- SNMP, described in [19],[27]-[41], has been widely deployed in a wide
../data/rfc/rfc2975.txt: variety of intra-domain accounting applications, typically using the
../data/rfc/rfc2975.txt- polling data collection model. Polling allows data to be collected
../data/rfc/rfc2975.txt: on multiple accounting events simultaneously, resulting in per-device
../data/rfc/rfc2975.txt- state. Management applications are able to retry requests when a
../data/rfc/rfc2975.txt- response is not received, providing resiliency against packet loss or
../data/rfc/rfc2975.txt- even short-lived network partitions. Implementations without non-
../data/rfc/rfc2975.txt- volatile storage are not robust against device reboots or network
../data/rfc/rfc2975.txt- failures, but when combined with non-volatile storage they can be
--
../data/rfc/rfc2975.txt- trap-directed polling, but the traps are not acknowledged, and lost
../data/rfc/rfc2975.txt- traps can lead to a loss of data. SMIv2, used by SNMPv2c and SNMPv3,
../data/rfc/rfc2975.txt- has Inform Requests which are acknowledged notifications. This makes
../data/rfc/rfc2975.txt- it possible to implement a more reliable event-driven polling model
../data/rfc/rfc2975.txt- or event-driven batching model. However, we are not aware of any
../data/rfc/rfc2975.txt: SNMP-based accounting implementations currently built on the use of
../data/rfc/rfc2975.txt- Informs.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-3.3.1. Security services
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- SNMPv1 and SNMPv2c support per-packet authentication and read-only
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 33]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- messages. The updated SNMP architecture [rfc2571] supports per-
../data/rfc/rfc2975.txt- packet hop-by-hop authentication, integrity and replay protection,
../data/rfc/rfc2975.txt- confidentiality and access control.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- The SNMP User Security Model (USM) [38] uses shared secrets, and when
../data/rfc/rfc2975.txt- the product of the number of domains and devices is large, such as in
../data/rfc/rfc2975.txt: inter-domain accounting applications, the number of shared secrets
../data/rfc/rfc2975.txt- can get out of hand. The localized key capability in USM allows a
../data/rfc/rfc2975.txt- manager to have one central key, sharing it with many SNMP entities
../data/rfc/rfc2975.txt- in a localized way while preventing the other entities from getting
../data/rfc/rfc2975.txt- at each other's data. This can assist in cross-domain security if
../data/rfc/rfc2975.txt- deployed properly.
--
../data/rfc/rfc2975.txt- There are eighteen SNMP error codes. The design of SNMP makes
../data/rfc/rfc2975.txt- service-specific error codes unnecessary and undesirable.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-3.3.3. Proxy forwarders
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: In the accounting management architecture, proxy forwarders play an
../data/rfc/rfc2975.txt: important role, forwarding intra and inter-domain accounting events
../data/rfc/rfc2975.txt- to the correct destinations. The proxy forwarder may also play a
../data/rfc/rfc2975.txt- role in a polling or event-driven polling architecture.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 34]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- The functionality of an SNMP Proxy Forwarder is defined in [39]. For
../data/rfc/rfc2975.txt- example, the network devices may be configured to send notifications
../data/rfc/rfc2975.txt- for all domains to the Proxy Forwarder, and the devices may be
../data/rfc/rfc2975.txt- configured to allow the Proxy Forwarder to access all MIB data.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- The use of proxy forwarders may reduce the number of shared secrets
../data/rfc/rfc2975.txt: required for inter-domain accounting. With Proxy Forwarders, the
../data/rfc/rfc2975.txt- domains could share a secret with the Proxy Forwarder, and in turn,
../data/rfc/rfc2975.txt- the Proxy Forwarder could share a secret with each of the devices.
../data/rfc/rfc2975.txt- Thus the number of shared secrets will scale with the sum of the
../data/rfc/rfc2975.txt- number of devices and domains rather than the product.
../data/rfc/rfc2975.txt-
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Domain-based access controls are required where multiple
../data/rfc/rfc2975.txt- administrative domains are involved, such as in the shared use
../data/rfc/rfc2975.txt- networks and roaming associations described in [1]. Since the same
../data/rfc/rfc2975.txt- device may be accessed by multiple organizations, it is often
../data/rfc/rfc2975.txt: necessary to control access to accounting data according to the
../data/rfc/rfc2975.txt- user's organization. This ensures that organizations may be given
../data/rfc/rfc2975.txt: access to accounting data relating to their users, but not to data
../data/rfc/rfc2975.txt- relating to users of other organizations.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- In order to apply domain-based access controls, in inter-domain
../data/rfc/rfc2975.txt: accounting, it is first necessary to identify the data subset that is
../data/rfc/rfc2975.txt- to have its access controlled. Several conceptual abstractions are
../data/rfc/rfc2975.txt- used for identifying subsets of data in SNMP. These include engines,
../data/rfc/rfc2975.txt- contexts, and views. This section describes how this functionality
../data/rfc/rfc2975.txt: may be applied in intra and inter-domain accounting.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-3.3.4.1. Engines
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- The new SNMP architecture, described in [27], added the concept of an
../data/rfc/rfc2975.txt- SNMP engine to improve mobility support and to identify which data
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 35]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- A securityEngineID field in a message identifies the engine which
../data/rfc/rfc2975.txt- provides access to the security credentials contained in the message
../data/rfc/rfc2975.txt- header. A contextEngineID field in a message identifies the engine
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 36]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-3.3.4.3. Views
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Views are defined in the View-based Access Control Model. A view is
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- As the number of network devices within the shared use or roaming
../data/rfc/rfc2975.txt- network grows, the polling model of data collection becomes
../data/rfc/rfc2975.txt- increasingly impractical since most devices will not carry data
../data/rfc/rfc2975.txt- relating to the polling organization. As a result, shared-use
../data/rfc/rfc2975.txt: networks or roaming associations relying on SNMP-based accounting
../data/rfc/rfc2975.txt- have generally collected data for all organizations and then sorted
../data/rfc/rfc2975.txt- the resulting session records for delivery to each organization.
../data/rfc/rfc2975.txt- While functional, this approach will typically result in increased
../data/rfc/rfc2975.txt- processing delay as the number of organizations and data records
../data/rfc/rfc2975.txt- grows.
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 37]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: accounting data awaiting collection. SNMP Applications [39] defines
../data/rfc/rfc2975.txt- a standard module for managing notifications.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- To use the event-driven approaches, the device must be able to
../data/rfc/rfc2975.txt- determine when information is available for a domain. Domain-
../data/rfc/rfc2975.txt- specific data can be differentiated at the SNMP agent level through
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 38]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- synchronization between tables.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-3.3.5.2. Contexts
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Individual domains, such as bigco.com, could be mapped to logical
../data/rfc/rfc2975.txt- contexts, such as a bigco context. The agent would need to create
../data/rfc/rfc2975.txt- and recognize new contexts and to know which instrumentation is
../data/rfc/rfc2975.txt- associated with the logical context. The agent needs to collect
../data/rfc/rfc2975.txt: accounting data by domain and make the data accessible via distinct
../data/rfc/rfc2975.txt- contexts, so that access control can be applied to the context to
../data/rfc/rfc2975.txt- prevent disclosure of sensitive information to the wrong domain. The
../data/rfc/rfc2975.txt- VACM access control views are applied relative to the context, so an
../data/rfc/rfc2975.txt- operation can be permitted or denied a user based on the context
../data/rfc/rfc2975.txt- which contains the data.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Domain separation is handled by using contextName to differentiate
../data/rfc/rfc2975.txt: multiple virtual tables. For example, if accounting data has been
../data/rfc/rfc2975.txt- collected on users with the bigco.com and smallco.com domains, then a
../data/rfc/rfc2975.txt: separate virtual instance of the accounting session record table
../data/rfc/rfc2975.txt- would exist for each domain, and each domain would have a
../data/rfc/rfc2975.txt- corresponding contextName. When a get-bulk request is made with a
../data/rfc/rfc2975.txt- contextName of bigco, then data from the virtual table in the bigco
../data/rfc/rfc2975.txt- context, i.e. corresponding to the bigco.com domain, would be
../data/rfc/rfc2975.txt- returned.
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 39]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- condition, and what access control rules apply to the context.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Either technique could associate existing MIB modules to domain-
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- There are issues that arise when using SNMP for transfer of bulk
../data/rfc/rfc2975.txt- data, including issues of latency, network overhead, and table
../data/rfc/rfc2975.txt- retrieval, as discussed in [49].
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: In accounting applications, management stations often must retrieve
../data/rfc/rfc2975.txt- large tables. Latency can be high, even with the get-bulk operation,
../data/rfc/rfc2975.txt- because the response must fit into the largest supported packet size,
../data/rfc/rfc2975.txt- requiring multiple round-trips. Transfers may be serialized and the
../data/rfc/rfc2975.txt- resulting latency will be a combination of multiple round-trip times,
../data/rfc/rfc2975.txt- possible timeout and re-transmission delays and processing overhead,
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 40]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- that it is possible to stop at the end of a table.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-3.3.6.1. Ongoing research
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 41]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Issues of legacy support exist with the NMRG proposals. Devices
../data/rfc/rfc2975.txt- which do not implement the new functionality would need to be
../data/rfc/rfc2975.txt- accommodated. This is especially problematic for proxy forwarders,
--
../data/rfc/rfc2975.txt- of identification. Thus, an IPSEC-based security model for SNMPv3
../data/rfc/rfc2975.txt- would probably take several years to come to fruition.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-3.3.7. SNMP summary
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Given the wealth of existing accounting-related MIB modules, it is
../data/rfc/rfc2975.txt: likely that SNMP will remain a popular accounting protocol for the
../data/rfc/rfc2975.txt- foreseeable future.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 42]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Support for notifications makes it possible to implement the event-
../data/rfc/rfc2975.txt- driven, event-driven polling and event-driven batching models. This
../data/rfc/rfc2975.txt- makes it possible to notify domains of available data rather than
../data/rfc/rfc2975.txt- requiring them to poll for it, which is critical in shared use
../data/rfc/rfc2975.txt- networks and roaming.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Given the SNMPv3 security enhancements, it is desirable for SNMP-
../data/rfc/rfc2975.txt: based intra-domain accounting implementations to upgrade to SNMPv3.
../data/rfc/rfc2975.txt- Such an upgrade is virtually mandatory for inter-domain applications.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: In inter-domain accounting, the burden of managing SNMPv3 shared
../data/rfc/rfc2975.txt- secrets can be reduced via the localized key capability or via
../data/rfc/rfc2975.txt- implementation of a Proxy Forwarder. In the long term, alternative
../data/rfc/rfc2975.txt- security models such as the Kerberos Security Model may further
../data/rfc/rfc2975.txt- reduce the effort required to manage security and enable streamlined
../data/rfc/rfc2975.txt- inter-domain operation.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: SNMP-based accounting has limitations in terms of efficiency and
../data/rfc/rfc2975.txt- latency that may make it inappropriate for use in situations
../data/rfc/rfc2975.txt- requiring low processing delay or low overhead. This includes usage
../data/rfc/rfc2975.txt- sensitive billing applications where fraud detection may be required.
../data/rfc/rfc2975.txt- These issues can be addressed via proposals under discussion in the
../data/rfc/rfc2975.txt- IRTF Network Management Research Group (NMRG). The experimental SNMP
--
../data/rfc/rfc2975.txt- worth considering. However, since these proposals are still in the
../data/rfc/rfc2975.txt- research stage, and are not on the standards track, these
../data/rfc/rfc2975.txt- capabilities are not readily available, and the specifications could
../data/rfc/rfc2975.txt- change considerably before they reach their final form.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: SNMP supports separation of accounting data by domain, using either
../data/rfc/rfc2975.txt- of two general approaches with the VACM access control model. The
../data/rfc/rfc2975.txt- domain as index approach can be used if the desired MIB module
../data/rfc/rfc2975.txt- supports domain indexing, or it can implemented using an additional
../data/rfc/rfc2975.txt- table. The domain-context approach can be used in agents which
../data/rfc/rfc2975.txt- support dynamic logical contexts and a domain-to-context and
../data/rfc/rfc2975.txt- context-to-instrumentation mapping mechanism. Either approach can be
../data/rfc/rfc2975.txt- supported using SNMPv1, SNMPv2c, or SNMPv3 messages, by utilizing the
../data/rfc/rfc2975.txt- snmpCommunitytable [11] to provide a community-to-context mapping.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:4. Review of Accounting Data Transfer
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: In order for session records to be transmitted between accounting
../data/rfc/rfc2975.txt- servers, a transfer protocol is required. Transfer protocols in use
../data/rfc/rfc2975.txt: today include SMTP, FTP, and HTTP. For a review of accounting
../data/rfc/rfc2975.txt- attributes and record formats, see [45].
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 43]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Reference [49] contains a discussion of alternative encodings for SMI
../data/rfc/rfc2975.txt- data types, as well as alternative protocols for transmission of
../data/rfc/rfc2975.txt: accounting data. For example, [49] describes how MIME tags and XML
../data/rfc/rfc2975.txt- DTDs may be used for encoding of SNMP messages or SMI data types.
../data/rfc/rfc2975.txt- This enables data from SNMP MIBs to be transported using any protocol
../data/rfc/rfc2975.txt- that can encapsulate MIME or XML, including SMTP and HTTP.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-4.1. SMTP
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: To date, few accounting management systems have been built on SMTP
../data/rfc/rfc2975.txt- since the implementation of a store-and-forward message system has
../data/rfc/rfc2975.txt- traditionally required access to non-volatile storage which has not
../data/rfc/rfc2975.txt- been widely available on network devices. However, SMTP-based
../data/rfc/rfc2975.txt- implementations have many desirable characteristics, particularly
../data/rfc/rfc2975.txt- with regards to security.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Accounting management systems using SMTP for accounting transfer will
../data/rfc/rfc2975.txt- typically support batching so that message processing overhead will
../data/rfc/rfc2975.txt: be spread over multiple accounting records. As a result, these
../data/rfc/rfc2975.txt: systems result in per-active device state. Since accounting systems
../data/rfc/rfc2975.txt- using SMTP as a transfer mechanism have access to substantial non-
../data/rfc/rfc2975.txt- volatile storage, they can generate, compress if necessary, and store
../data/rfc/rfc2975.txt: accounting records until they are transferred to the collection site.
../data/rfc/rfc2975.txt: As a result, accounting systems implemented using SMTP can be highly
../data/rfc/rfc2975.txt- efficient and scalable. Using IPSEC, TLS or Kerberos, hop-by-hop
../data/rfc/rfc2975.txt- security services such as authentication, integrity protection and
../data/rfc/rfc2975.txt- confidentiality can be provided.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- As described in [13] and [15], data object security is available for
../data/rfc/rfc2975.txt- SMTP, and in addition, the facilities described in [12] make it
../data/rfc/rfc2975.txt- possible to request and receive signed receipts, which enables non-
../data/rfc/rfc2975.txt: repudiation as described in [12]-[17]. As a result, accounting
../data/rfc/rfc2975.txt: systems utilizing SMTP for accounting data transfer are capable of
../data/rfc/rfc2975.txt- satisfying the most demanding security requirements. However, such
../data/rfc/rfc2975.txt- systems are not typically capable of providing low processing delay,
../data/rfc/rfc2975.txt- although this may be addressed by the enhancements described in [20].
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-4.2. Other protocols
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- File transfer protocols such as FTP and HTTP have been used for
../data/rfc/rfc2975.txt: transfer of accounting data. For example, Reference [9] describes a
../data/rfc/rfc2975.txt: means for representing ASN.1-based accounting data for storage on
../data/rfc/rfc2975.txt: archival media. Through the use of the Bulk File MIB, accounting
../data/rfc/rfc2975.txt- data from an SNMP MIB can be stored in ASN.1, bulk binary or Bulk
../data/rfc/rfc2975.txt- ASCII format, and then subsequently retrieved as required using the
../data/rfc/rfc2975.txt- FTP Client MIB.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 44]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Given access to sufficient non-volatile storage, accounting systems
../data/rfc/rfc2975.txt- based on record formats and transfer protocols can avoid loss of data
../data/rfc/rfc2975.txt- due to long-duration network partitions, server failures or device
../data/rfc/rfc2975.txt- reboots. Since it is possible for the transfer to be driven from the
../data/rfc/rfc2975.txt- collection site, the collector can retry transfers until successful,
../data/rfc/rfc2975.txt- or with HTTP may even be able to restart partially completed
../data/rfc/rfc2975.txt- transfers. As a result, file transfer-based systems can be made
../data/rfc/rfc2975.txt: highly reliable, and the batching of accounting records makes
../data/rfc/rfc2975.txt- possible efficient transfers and application of required security
../data/rfc/rfc2975.txt- services with lessened overhead.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-5. Summary
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: As noted previously in this document, accounting applications vary in
../data/rfc/rfc2975.txt- their security and reliability requirements. Some uses such as
../data/rfc/rfc2975.txt- capacity planning may only require authentication, integrity and
../data/rfc/rfc2975.txt- replay protection, and modest reliability. Other applications such
../data/rfc/rfc2975.txt- as inter-domain usage-sensitive billing may require the highest
../data/rfc/rfc2975.txt- degree of security and reliability, since in these cases the transfer
../data/rfc/rfc2975.txt: of accounting data will lead directly to the transfer of funds.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: Since accounting applications do not have uniform security and
../data/rfc/rfc2975.txt- reliability requirements, it is not possible to devise a single
../data/rfc/rfc2975.txt: accounting protocol and set of security services that will meet all
../data/rfc/rfc2975.txt: needs. Rather, the goal of accounting management should be to
../data/rfc/rfc2975.txt: provide a set of tools that can be used to construct accounting
../data/rfc/rfc2975.txt- systems meeting the requirements of an individual application. As a
../data/rfc/rfc2975.txt: result, it is important to analyze a given accounting application to
../data/rfc/rfc2975.txt- ensure that the methods chosen meet the security and reliability
../data/rfc/rfc2975.txt- requirements of the application.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Based on an analysis of the requirements, it appears that existing
../data/rfc/rfc2975.txt- deployed protocols are capable of meeting the requirements for
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 45]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- For usage sensitive billing, as well as cost allocation and auditing
../data/rfc/rfc2975.txt- applications, the reliability requirement are greater. Here
../data/rfc/rfc2975.txt- transport layer reliability is required to provide robustness against
../data/rfc/rfc2975.txt- packet loss, as well as application layer acknowledgments to provide
../data/rfc/rfc2975.txt: robustness against accounting server failures. SNMP operations with
../data/rfc/rfc2975.txt- the exception of InforRequest provide application layer
../data/rfc/rfc2975.txt- acknowledgments, and the TCP transport mapping proposed by NMRG
../data/rfc/rfc2975.txt- provides robustness against packet loss. Inter-domain operation can
../data/rfc/rfc2975.txt- benefit from data object security (which no existing protocol
../data/rfc/rfc2975.txt- provides) as well as inter-domain security model enhancements (such
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 46]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
../data/rfc/rfc2975.txt- | | | |
../data/rfc/rfc2975.txt- | Usage | Intra-domain | Inter-domain |
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 47]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-6. Security Considerations
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Security issues are discussed throughout this memo.
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- [3] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
../data/rfc/rfc2975.txt- Authentication Dial In User Service (RADIUS)", RFC 2138, April,
../data/rfc/rfc2975.txt- 1997.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: [4] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- [5] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP Payload
../data/rfc/rfc2975.txt- Compression Protocol (IPComp)", RFC 2393, December 1998.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- [8] Aboba, B. and M. Beadles, "The Network Access Identifier",
../data/rfc/rfc2975.txt- RFC 2486, January 1999.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- [9] McCloghrie, K., Heinanen, J., Greene, W. and A. Prasad,
../data/rfc/rfc2975.txt: "Accounting Information for ATM Networks", RFC 2512, February
../data/rfc/rfc2975.txt- 1999.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- [10] McCloghrie, K., Heinanen, J., Greene, W., and A. Prasad,
../data/rfc/rfc2975.txt- "Managed Objects for Controlling the Collection and Storage of
../data/rfc/rfc2975.txt: Accounting Information for Connection-Oriented Networks", RFC
../data/rfc/rfc2975.txt- 2513, February 1999.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- [11] Frye, R., Levi, D., Routhier, S. and B. Wijnen, "Coexistence
../data/rfc/rfc2975.txt- between Version 1, Version 2, and Version 3 of the Internet-
../data/rfc/rfc2975.txt- standard Management Framework", RFC 2576, March 2000.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 48]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- [12] Fajman, R., "An Extensible Message Format for Message
../data/rfc/rfc2975.txt- Disposition Notifications", RFC 2298, March 1998.
../data/rfc/rfc2975.txt-
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- [20] Klyne, G., "Timely Delivery for Facsimile Using Internet Mail",
../data/rfc/rfc2975.txt- Work in Progress.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- [21] Johnson, H. T., Kaplan, R. S., Relevance Lost: The Rise and Fall
../data/rfc/rfc2975.txt: of Management Accounting, Harvard Business School Press, Boston,
../data/rfc/rfc2975.txt- Massachusetts, 1987.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: [22] Horngren, C. T., Foster, G., Cost Accounting: A Managerial
../data/rfc/rfc2975.txt- Emphasis. Prentice Hall, Englewood Cliffs, New Jersey, 1991.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- [23] Kaplan, R. S., Atkinson, Anthony A., Advanced Management
../data/rfc/rfc2975.txt: Accounting, Prentice Hall, Englewood Cliffs, New Jersey, 1989.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- [24] Cooper, R., Kaplan, R. S., The Design of Cost Management
../data/rfc/rfc2975.txt- Systems. Prentice Hall, Englewood Cliffs, New Jersey, 1991.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- [25] Rigney, C., Willats, S. and P. Calhoun, "RADIUS Extensions", RFC
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 49]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- [26] Stewart, R., et al., "Simple Control Transmission Protocol", RFC
../data/rfc/rfc2975.txt- 2960, October 2000.
../data/rfc/rfc2975.txt-
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 50]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- [40] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
../data/rfc/rfc2975.txt- Control Model (VACM) for the Simple Network Management Protocol
../data/rfc/rfc2975.txt- (SNMP)", RFC 2575, April 1999.
--
../data/rfc/rfc2975.txt- Realm Authentication in Kerberos", Work in Progress.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- [44] Hornstein, K. and W. Hardaker, "A Kerberos Security Model for
../data/rfc/rfc2975.txt- SNMPv3", Work in Progress.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt: [45] Brownlee, N. and A. Blount, "Accounting Attributes and Record
../data/rfc/rfc2975.txt- Formats", RFC 2924, September 2000.
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- [46] Network Management Research Group Web page,
../data/rfc/rfc2975.txt- http://www.ibr.cs.tu-bs.de/projects/nmrg/
../data/rfc/rfc2975.txt-
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 51]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-9. Authors' Addresses
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Bernard Aboba
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 52]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-10. Intellectual Property Statement
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- The IETF takes no position regarding the validity or scope of any
--
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-Aboba, et al. Informational [Page 53]
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt:RFC 2975 Introduction to Accounting Management October 2000
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt-11. Full Copyright Statement
../data/rfc/rfc2975.txt-
../data/rfc/rfc2975.txt- Copyright (C) The Internet Society (2000). All Rights Reserved.
--
../data/rfc/rfc5897.txt- 4. Using Service Identification ....................................8
../data/rfc/rfc5897.txt- 4.1. Application Invocation in the User Agent ...................8
../data/rfc/rfc5897.txt- 4.2. Application Invocation in the Network ......................9
../data/rfc/rfc5897.txt- 4.3. Network Quality-of-Service Authorization ..................10
../data/rfc/rfc5897.txt- 4.4. Service Authorization .....................................10
../data/rfc/rfc5897.txt: 4.5. Accounting and Billing ....................................11
../data/rfc/rfc5897.txt- 4.6. Negotiation of Service ....................................11
../data/rfc/rfc5897.txt- 4.7. Dispatch to Devices .......................................11
../data/rfc/rfc5897.txt- 5. Key Principles of Service Identification .......................12
../data/rfc/rfc5897.txt- 5.1. Services Are a By-Product of Signaling ....................12
../data/rfc/rfc5897.txt- 5.2. Identical Signaling Produces Identical Services ...........13
--
../data/rfc/rfc5897.txt-4. Using Service Identification
../data/rfc/rfc5897.txt-
../data/rfc/rfc5897.txt- It is important to understand what the service identity would be
../data/rfc/rfc5897.txt- utilized for, if known. This section discusses the primary uses.
../data/rfc/rfc5897.txt- These are application invocation in user agents and the network,
../data/rfc/rfc5897.txt: Quality of Service authorization, service authorization, accounting
../data/rfc/rfc5897.txt- and billing, service negotiation, and device dispatch.
../data/rfc/rfc5897.txt-
../data/rfc/rfc5897.txt-4.1. Application Invocation in the User Agent
../data/rfc/rfc5897.txt-
../data/rfc/rfc5897.txt- In some of the examples above, there were multiple software
--
../data/rfc/rfc5897.txt-
../data/rfc/rfc5897.txt- Consequently, when an INVITE arrives at a server in the network, the
../data/rfc/rfc5897.txt- server will need to determine what the requested service is, so that
../data/rfc/rfc5897.txt- the server can make an authorization decision.
../data/rfc/rfc5897.txt-
../data/rfc/rfc5897.txt:4.5. Accounting and Billing
../data/rfc/rfc5897.txt-
../data/rfc/rfc5897.txt: Service authorization and accounting/billing go hand in hand. One of
../data/rfc/rfc5897.txt- the primary reasons for authorizing that a user can utilize a service
../data/rfc/rfc5897.txt- is that they are being billed differently based on the type of
../data/rfc/rfc5897.txt- service. Consequently, one of the goals of a service identity is to
../data/rfc/rfc5897.txt: be able to include it in accounting records, so that the appropriate
../data/rfc/rfc5897.txt- billing model can be applied.
../data/rfc/rfc5897.txt-
../data/rfc/rfc5897.txt- For example, in the case of IPTV, a service provider can bill based
../data/rfc/rfc5897.txt- on the content (US $5 per movie, perhaps), whereas for multimedia
../data/rfc/rfc5897.txt- conferencing, they can bill by the minute. This requires the
../data/rfc/rfc5897.txt: accounting streams to indicate which service was invoked for the
../data/rfc/rfc5897.txt- particular session.
../data/rfc/rfc5897.txt-
../data/rfc/rfc5897.txt-4.6. Negotiation of Service
../data/rfc/rfc5897.txt-
../data/rfc/rfc5897.txt- In some cases, when the caller initiates a session, they don't
--
../data/rfc/rfc5897.txt- 3. Declarative service identification can stifle service innovation
../data/rfc/rfc5897.txt-
../data/rfc/rfc5897.txt-6.1. Fraud
../data/rfc/rfc5897.txt-
../data/rfc/rfc5897.txt- Declarative service identification can lead to fraud. If a provider
../data/rfc/rfc5897.txt: uses the service identifier for billing and accounting purposes, or
../data/rfc/rfc5897.txt- for authorization purposes, it opens an avenue for attack. The user
../data/rfc/rfc5897.txt- can construct the signaling message so that its actual effect (which
../data/rfc/rfc5897.txt- is the service the user will receive), is what the user desires, but
../data/rfc/rfc5897.txt- the user places a service identifier into the request (which is what
../data/rfc/rfc5897.txt- is used for billing and authorization) that identifies a cheaper
--
../data/rfc/rfc5897.txt- Domain 2 provides their users with a service they call "text
../data/rfc/rfc5897.txt- telephony", which is a voice service on a wireless device that also
../data/rfc/rfc5897.txt- allows the user to send text messages. Consider the case where
../data/rfc/rfc5897.txt- domain 1 and domain 2 both have their user agents insert a service
../data/rfc/rfc5897.txt- identifier into the request, and then use that to perform QoS
../data/rfc/rfc5897.txt: authorization, accounting, and invocation of applications in the
../data/rfc/rfc5897.txt- network and in the device. The user in domain 1 calls the user in
../data/rfc/rfc5897.txt- domain 2, and inserts the identifier "Voice Chat" into the INVITE.
../data/rfc/rfc5897.txt- When this arrives at the server in domain 2, the service identifier
../data/rfc/rfc5897.txt- is unknown. Consequently, the request does not get the proper QoS
../data/rfc/rfc5897.txt- treatment, even if the call itself will succeed.
--
../data/rfc/rfc5897.txt- Consider the following example. Several providers get together and
../data/rfc/rfc5897.txt- standardize on a bunch of service identifiers. One of these uses
../data/rfc/rfc5897.txt- audio and video (say, "multimedia conversation"). This service is
../data/rfc/rfc5897.txt- successful and is widely utilized. Endpoints look for this
../data/rfc/rfc5897.txt- identifier to dispatch calls to the right software applications, and
../data/rfc/rfc5897.txt: the network looks for it to invoke features, perform accounting, and
../data/rfc/rfc5897.txt- provide QoS. A new provider gets the idea for a new service (say,
../data/rfc/rfc5897.txt- "avatar-enhanced multimedia conversation"). In this service, there
../data/rfc/rfc5897.txt- is audio and video, but there is a third stream, which renders an
../data/rfc/rfc5897.txt- avatar. A caller can press buttons on their phone, to cause the
../data/rfc/rfc5897.txt- avatar on the other person's device to show emotion, make noise, and
--
../data/rfc/rfc5897.txt- of individual features that can be signaled in SIP.
../data/rfc/rfc5897.txt-
../data/rfc/rfc5897.txt-8. Security Considerations
../data/rfc/rfc5897.txt-
../data/rfc/rfc5897.txt- Oftentimes, the service associated with a request is utilized for
../data/rfc/rfc5897.txt: purposes such as authorization, accounting, and billing. When
../data/rfc/rfc5897.txt- service identification is not done properly, the possibility of
../data/rfc/rfc5897.txt- unauthorized service use and network fraud is introduced. It is for
../data/rfc/rfc5897.txt- this reason, discussed extensively in Section 6.1, that the usage of
../data/rfc/rfc5897.txt- declarative service identifiers inserted by a UA is not recommended.
../data/rfc/rfc5897.txt-
--
../data/rfc/rfc2970.txt- Because of its particular application to query-response situations,
../data/rfc/rfc2970.txt- the term "Directory Access Gateway", or "DAG" still fits as a label
../data/rfc/rfc2970.txt- for this type of system architecture.
../data/rfc/rfc2970.txt-
../data/rfc/rfc2970.txt- Internet applications are evolving, and require more sophisticated
../data/rfc/rfc2970.txt: features (e.g., security mechanisms, accounting mechanisms,
../data/rfc/rfc2970.txt- integration of historical session data). Continuing to develop a
../data/rfc/rfc2970.txt- dedicated protocol per application type results in encumbered and
../data/rfc/rfc2970.txt- unwieldy protocols, as each must implement coverage of all of these
../data/rfc/rfc2970.txt- common aspects. But creating a single multi-application protocol
../data/rfc/rfc2970.txt- seems unlikely at best. The implicit proposal here is that, rather
--
../data/rfc/rfc2970.txt-RFC 2970 Architecture for IDS - Result from TISDAG October 2000
../data/rfc/rfc2970.txt-
../data/rfc/rfc2970.txt-
../data/rfc/rfc2970.txt- 3. identification of necessary services -- e.g., proxying to
../data/rfc/rfc2970.txt- remote information search services, lookup services, "AAA[A]"
../data/rfc/rfc2970.txt: (Authentication, Authorization, Accounting, [and Access])
../data/rfc/rfc2970.txt- servers, etc
../data/rfc/rfc2970.txt- 4. definition of the transaction process for the service: insofar
../data/rfc/rfc2970.txt- as the CAPs represent the service to client software, CAP
../data/rfc/rfc2970.txt- modules manage the necessary transactions with other service
../data/rfc/rfc2970.txt- modules
--
../data/rfc/rfc2970.txt- include that it be:
../data/rfc/rfc2970.txt-
../data/rfc/rfc2970.txt- - lightweight; CAPs, SAPs should be able to be quite small
../data/rfc/rfc2970.txt- - flexible enough to carry queries of different paradigms, results
../data/rfc/rfc2970.txt- of different types
../data/rfc/rfc2970.txt: - able to support authentication, authorization, accounting and
../data/rfc/rfc2970.txt- audit mechanisms -- not necessarily native to the protocol
../data/rfc/rfc2970.txt- - able to support encryption and end-to-end security within the
../data/rfc/rfc2970.txt- DAG system
../data/rfc/rfc2970.txt- - sophisticated enough to allow negotiation of capabilities --
../data/rfc/rfc2970.txt- querying & identifying application type supported (e.g.,
--
../data/rfc/rfc2865.txt- appendix.
../data/rfc/rfc2865.txt-
../data/rfc/rfc2865.txt- Managing dispersed serial line and modem pools for large numbers of
../data/rfc/rfc2865.txt- users can create the need for significant administrative support.
../data/rfc/rfc2865.txt- Since modem pools are by definition a link to the outside world, they
../data/rfc/rfc2865.txt: require careful attention to security, authorization and accounting.
../data/rfc/rfc2865.txt- This can be best achieved by managing a single "database" of users,
../data/rfc/rfc2865.txt- which allows for authentication (verifying user name and password) as
../data/rfc/rfc2865.txt- well as configuration information detailing the type of service to
../data/rfc/rfc2865.txt- deliver to the user (for example, SLIP, PPP, telnet, rlogin).
../data/rfc/rfc2865.txt-
--
../data/rfc/rfc2865.txt- client.
../data/rfc/rfc2865.txt-
../data/rfc/rfc2865.txt-2.3. Proxy
../data/rfc/rfc2865.txt-
../data/rfc/rfc2865.txt- With proxy RADIUS, one RADIUS server receives an authentication (or
../data/rfc/rfc2865.txt: accounting) request from a RADIUS client (such as a NAS), forwards
../data/rfc/rfc2865.txt- the request to a remote RADIUS server, receives the reply from the
../data/rfc/rfc2865.txt- remote server, and sends that reply to the client, possibly with
../data/rfc/rfc2865.txt- changes to reflect local administrative policy. A common use for
../data/rfc/rfc2865.txt- proxy RADIUS is roaming. Roaming permits two or more administrative
../data/rfc/rfc2865.txt- entities to allow each other's users to dial in to either entity's
--
../data/rfc/rfc2865.txt- RADIUS Codes (decimal) are assigned as follows:
../data/rfc/rfc2865.txt-
../data/rfc/rfc2865.txt- 1 Access-Request
../data/rfc/rfc2865.txt- 2 Access-Accept
../data/rfc/rfc2865.txt- 3 Access-Reject
../data/rfc/rfc2865.txt: 4 Accounting-Request
../data/rfc/rfc2865.txt: 5 Accounting-Response
../data/rfc/rfc2865.txt- 11 Access-Challenge
../data/rfc/rfc2865.txt- 12 Status-Server (experimental)
../data/rfc/rfc2865.txt- 13 Status-Client (experimental)
../data/rfc/rfc2865.txt- 255 Reserved
../data/rfc/rfc2865.txt-
../data/rfc/rfc2865.txt: Codes 4 and 5 are covered in the RADIUS Accounting document [5].
../data/rfc/rfc2865.txt- Codes 12 and 13 are reserved for possible use, but are not further
../data/rfc/rfc2865.txt- mentioned here.
../data/rfc/rfc2865.txt-
../data/rfc/rfc2865.txt- Identifier
../data/rfc/rfc2865.txt-
--
../data/rfc/rfc2865.txt- Where an Attribute's description limits which kinds of packet it can
../data/rfc/rfc2865.txt- be contained in, this applies only to the packet types defined in
../data/rfc/rfc2865.txt- this document, namely Access-Request, Access-Accept, Access-Reject
../data/rfc/rfc2865.txt- and Access-Challenge (Codes 1, 2, 3, and 11). Other documents
../data/rfc/rfc2865.txt- defining other packet types may also use Attributes described here.
../data/rfc/rfc2865.txt: To determine which Attributes are allowed in Accounting-Request and
../data/rfc/rfc2865.txt: Accounting-Response packets (Codes 4 and 5) refer to the RADIUS
../data/rfc/rfc2865.txt: Accounting document [5].
../data/rfc/rfc2865.txt-
../data/rfc/rfc2865.txt- Likewise where packet types defined here state that only certain
../data/rfc/rfc2865.txt- Attributes are permissible in them, future memos defining new
../data/rfc/rfc2865.txt- Attributes should indicate which packet types the new Attributes may
../data/rfc/rfc2865.txt- be present in.
--
../data/rfc/rfc2865.txt- 35 Login-LAT-Node
../data/rfc/rfc2865.txt- 36 Login-LAT-Group
../data/rfc/rfc2865.txt- 37 Framed-AppleTalk-Link
../data/rfc/rfc2865.txt- 38 Framed-AppleTalk-Network
../data/rfc/rfc2865.txt- 39 Framed-AppleTalk-Zone
../data/rfc/rfc2865.txt: 40-59 (reserved for accounting)
../data/rfc/rfc2865.txt- 60 CHAP-Challenge
../data/rfc/rfc2865.txt- 61 NAS-Port-Type
../data/rfc/rfc2865.txt- 62 Port-Limit
../data/rfc/rfc2865.txt- 63 Login-LAT-Port
../data/rfc/rfc2865.txt-
--
../data/rfc/rfc2865.txt- This Attribute indicates the name of the user to be authenticated.
../data/rfc/rfc2865.txt- It MUST be sent in Access-Request packets if available.
../data/rfc/rfc2865.txt-
../data/rfc/rfc2865.txt- It MAY be sent in an Access-Accept packet, in which case the
../data/rfc/rfc2865.txt- client SHOULD use the name returned in the Access-Accept packet in
../data/rfc/rfc2865.txt: all Accounting-Request packets for this session. If the Access-
../data/rfc/rfc2865.txt- Accept includes Service-Type = Rlogin and the User-Name attribute,
../data/rfc/rfc2865.txt- a NAS MAY use the returned User-Name when performing the Rlogin
../data/rfc/rfc2865.txt- function.
../data/rfc/rfc2865.txt-
../data/rfc/rfc2865.txt- A summary of the User-Name Attribute format is shown below. The
--
../data/rfc/rfc2865.txt-
../data/rfc/rfc2865.txt- Description
../data/rfc/rfc2865.txt-
../data/rfc/rfc2865.txt- This Attribute is available to be sent by the server to the client
../data/rfc/rfc2865.txt- in an Access-Accept and SHOULD be sent unmodified by the client to
../data/rfc/rfc2865.txt: the accounting server as part of the Accounting-Request packet if
../data/rfc/rfc2865.txt: accounting is supported. The client MUST NOT interpret the
../data/rfc/rfc2865.txt- attribute locally.
../data/rfc/rfc2865.txt-
../data/rfc/rfc2865.txt- A summary of the Class Attribute format is shown below. The fields
../data/rfc/rfc2865.txt- are transmitted from left to right.
../data/rfc/rfc2865.txt-
--
../data/rfc/rfc2865.txt- Packet Type Codes, Attribute Types, and Attribute Values (for certain
../data/rfc/rfc2865.txt- Attributes).
../data/rfc/rfc2865.txt-
../data/rfc/rfc2865.txt- RADIUS is not intended as a general-purpose Network Access Server
../data/rfc/rfc2865.txt- (NAS) management protocol, and allocations should not be made for
../data/rfc/rfc2865.txt: purposes unrelated to Authentication, Authorization or Accounting.
../data/rfc/rfc2865.txt-
../data/rfc/rfc2865.txt-6.1. Definition of Terms
../data/rfc/rfc2865.txt-
../data/rfc/rfc2865.txt- The following terms are used here with the meanings defined in
../data/rfc/rfc2865.txt- BCP 26: "name space", "assigned value", "registration".
--
../data/rfc/rfc2865.txt- Updated list of attributes that can be included in Access-Challenge
../data/rfc/rfc2865.txt- to be consistent with the table of attributes.
../data/rfc/rfc2865.txt-
../data/rfc/rfc2865.txt- User-Name mentions Network Access Identifiers.
../data/rfc/rfc2865.txt-
../data/rfc/rfc2865.txt: User-Name may now be sent in Access-Accept for use with accounting
../data/rfc/rfc2865.txt- and Rlogin.
../data/rfc/rfc2865.txt-
../data/rfc/rfc2865.txt- Values added for Service-Type, Login-Service, Framed-Protocol,
../data/rfc/rfc2865.txt- Framed-Compression, and NAS-Port-Type.
../data/rfc/rfc2865.txt-
--
../data/rfc/rfc2865.txt- RFC 1321, April 1992.
../data/rfc/rfc2865.txt-
../data/rfc/rfc2865.txt- [4] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
../data/rfc/rfc2865.txt- 1980.
../data/rfc/rfc2865.txt-
../data/rfc/rfc2865.txt: [5] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc2865.txt-
../data/rfc/rfc2865.txt- [6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
../data/rfc/rfc2865.txt- 1700, October 1994.
../data/rfc/rfc2865.txt-
../data/rfc/rfc2865.txt- [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
--
../data/rfc/rfc5685.txt-
../data/rfc/rfc5685.txt- In case the IKE_AUTH exchange involves Extensible Authentication
../data/rfc/rfc5685.txt- Protocol (EAP) authentication (as described in Section 2.16 of RFC
../data/rfc/rfc5685.txt- 4306 [2]) or multiple authentication methods (as described in RFC
../data/rfc/rfc5685.txt- 4739 [6]), the gateway may decide to redirect the client based on the
../data/rfc/rfc5685.txt: interaction with the Authentication, Authorization, and Accounting
../data/rfc/rfc5685.txt- (AAA) server or the external authentication server. In this case,
../data/rfc/rfc5685.txt- the gateway MUST send the REDIRECT Notify payload in either the first
../data/rfc/rfc5685.txt- or the last IKE_AUTH response. The client and the gateway MUST
../data/rfc/rfc5685.txt- verify the AUTH payloads as described above.
../data/rfc/rfc5685.txt-
--
../data/rfc/rfc617.txt-functions), it merely maps FTP commands into local commands which
../data/rfc/rfc617.txt-it "types" on a pseudo-Teletype (PTY) to a subjob, and similarly
../data/rfc/rfc617.txt-maps local responses into FTP responses.
../data/rfc/rfc617.txt-
../data/rfc/rfc617.txt-This scheme makes maximum use of existing software and
../data/rfc/rfc617.txt:mechanisms for user authentication, accounting, and file
../data/rfc/rfc617.txt-access, and eliminates the need for the (privileged) FTP server
../data/rfc/rfc617.txt-to perform them interpretively. (This conforms to the
../data/rfc/rfc617.txt-"principle of least privilege" described in RFC 501, NIC
../data/rfc/rfc617.txt-#15818.)
../data/rfc/rfc617.txt-
--
../data/rfc/rfc2888.txt- the purposes of this document.
../data/rfc/rfc2888.txt-
../data/rfc/rfc2888.txt-3. Remote Access operation
../data/rfc/rfc2888.txt-
../data/rfc/rfc2888.txt- Remote access is more than mere authentication of remote clients by a
../data/rfc/rfc2888.txt: Network Access Server(NAS). Authentication, Authorization, Accounting
../data/rfc/rfc2888.txt- and routing are integral to remote access. A client must first pass
../data/rfc/rfc2888.txt- the authentication test before being granted link access to the
../data/rfc/rfc2888.txt- network. Network level services (such as IP) are granted based on the
../data/rfc/rfc2888.txt- authorization characteristics specified for the user in RADIUS.
../data/rfc/rfc2888.txt- Network Access Servers use RADIUS to scale for large numbers of users
--
../data/rfc/rfc1147.txt- configuration data as well as the modification of MIB
../data/rfc/rfc1147.txt- configuration data. The performance monitoring tool
../data/rfc/rfc1147.txt- supports the collection and analysis of statistical
../data/rfc/rfc1147.txt- parameters from network devices. The status monitoring
../data/rfc/rfc1147.txt- tool reports on the up/down status and responsiveness
../data/rfc/rfc1147.txt: of network devices using ICMP. The accounting tool is
../data/rfc/rfc1147.txt- used to collect, store, and display user job activity
../data/rfc/rfc1147.txt- at the subscriber hosts. The NCC database entry sup-
../data/rfc/rfc1147.txt- ports RFC 1066 object definitions and Unisys-specific
../data/rfc/rfc1147.txt- object definitions to support the Unisys FDDI devices.
../data/rfc/rfc1147.txt- And finally, the trap reporting tool reports the
--
../data/rfc/rfc3103.txt-
../data/rfc/rfc3103.txt- This indicates that there is a conflict between flow-based policy and
../data/rfc/rfc3103.txt- support for gateways. The main purpose of enforcing flow-based
../data/rfc/rfc3103.txt- policy for LISTEN_REQUESTs is that it allows an RSIP gateway tight
../data/rfc/rfc3103.txt- control over how an RSIP host uses ports and the associated
../data/rfc/rfc3103.txt: accounting. For example, an RSIP host, operating under remote
../data/rfc/rfc3103.txt- micro-flow based policy and using a protocol such as FTP, will have
../data/rfc/rfc3103.txt- to specify the address and port that it will receive FTP data on, as
../data/rfc/rfc3103.txt- well as the address and port that the gateway will transmit data
../data/rfc/rfc3103.txt- from, in a LISTEN_REQUEST.
../data/rfc/rfc3103.txt-
--
../data/rfc/rfc1636.txt-
../data/rfc/rfc1636.txt- o Realtime Packet scheduling (realtime)
../data/rfc/rfc1636.txt-
../data/rfc/rfc1636.txt- o Mobility
../data/rfc/rfc1636.txt-
../data/rfc/rfc1636.txt: o Accounting
../data/rfc/rfc1636.txt-
../data/rfc/rfc1636.txt- (and maybe large-scale?)
../data/rfc/rfc1636.txt-
../data/rfc/rfc1636.txt- These categories were then applied to the following scenarios:
../data/rfc/rfc1636.txt-
--
../data/rfc/rfc1636.txt- S2. The group in S1 is 1/3 the Internet, i.e., there are VERY severe
../data/rfc/rfc1636.txt- scaling problems. [Security-S, mcast-S, realtime, mobility,
../data/rfc/rfc1636.txt- large-scale]
../data/rfc/rfc1636.txt-
../data/rfc/rfc1636.txt- S3. Charge for communication to support a video teleconference.
../data/rfc/rfc1636.txt: [Accounting, realtime, mcast-S]
../data/rfc/rfc1636.txt-
../data/rfc/rfc1636.txt- S4. I am travelling with my laptop. I tune in to radio channel IP-
../data/rfc/rfc1636.txt- RADIO, pick-up the beacon and start using it. Who gets the
../data/rfc/rfc1636.txt- bill? Why do they believe this is me? Is "me" a piece of
../data/rfc/rfc1636.txt- hardware (IP address) or a certified user (PEM certificate)?
../data/rfc/rfc1636.txt: [Mobility, accounting (, realtime, mcast-S)]
../data/rfc/rfc1636.txt-
../data/rfc/rfc1636.txt- S5. A Politically Important Person will mcast an Internet
../data/rfc/rfc1636.txt- presentation, without danger of interruptions from the audience.
../data/rfc/rfc1636.txt-
../data/rfc/rfc1636.txt- S6. The travel industry wants to use Internet to deliver tickets to
--
../data/rfc/rfc2002.txt-
../data/rfc/rfc2002.txt- When the mobile node receives an Agent Advertisement with the 'R' bit
../data/rfc/rfc2002.txt- set, the mobile node SHOULD register through the foreign agent, even
../data/rfc/rfc2002.txt- when the mobile node might be able to acquire its own co-located
../data/rfc/rfc2002.txt- care-of address. This feature is intended to allow sites to enforce
../data/rfc/rfc2002.txt: visiting policies (such as accounting) which require exchanges of
../data/rfc/rfc2002.txt- authorization.
../data/rfc/rfc2002.txt-
../data/rfc/rfc2002.txt-2.4.2. Move Detection
../data/rfc/rfc2002.txt-
../data/rfc/rfc2002.txt- Two primary mechanisms are provided for mobile nodes to detect when
--
../data/rfc/rfc1718.txt-
../data/rfc/rfc1718.txt- For those who could not attend a meeting but would like a copy of the
../data/rfc/rfc1718.txt- proceedings, send a check for US$35 (made payable to CNRI) to:
../data/rfc/rfc1718.txt-
../data/rfc/rfc1718.txt- Corporation for National Research Initiatives
../data/rfc/rfc1718.txt: Attn: Accounting Department - IETF Proceedings
../data/rfc/rfc1718.txt- 1895 Preston White Drive, Suite 100
../data/rfc/rfc1718.txt- Reston, VA 22091
../data/rfc/rfc1718.txt- USA
../data/rfc/rfc1718.txt-
../data/rfc/rfc1718.txt- Please indicate which meeting proceedings you would like to receive
--
../data/rfc/rfc3170.txt- entry D4 in Table 1. The initial unicast request is the only
../data/rfc/rfc3170.txt- difference between this type of application and a typical 1toM.
../data/rfc/rfc3170.txt- If that initial request were sent to a multicast address, this
../data/rfc/rfc3170.txt- would effectively be an MtoM application.
../data/rfc/rfc3170.txt-
../data/rfc/rfc3170.txt: t) Accounting: This is basically data collection but is worth
../data/rfc/rfc3170.txt- separating since it is such an important application. In some
../data/rfc/rfc3170.txt- multicast applications it is imperative to know information
../data/rfc/rfc3170.txt- about each receiver, possibly in real-time. But such
../data/rfc/rfc3170.txt- information can be overwhelming [MRM]. Current mechanisms,
../data/rfc/rfc3170.txt- like RTCP (which is actually MtoM since it is multicast but
--
../data/rfc/rfc4739.txt-
../data/rfc/rfc4739.txt- To take another example, when an operator is hosting a Virtual
../data/rfc/rfc4739.txt- Private Network (VPN) gateway service for a third party, it may be
../data/rfc/rfc4739.txt- necessary to authenticate the client to both the operator (for
../data/rfc/rfc4739.txt- billing purposes) and the third party's Authentication,
../data/rfc/rfc4739.txt: Authorization, and Accounting (AAA) server (for authorizing access to
../data/rfc/rfc4739.txt- the third party's internal network).
../data/rfc/rfc4739.txt-
../data/rfc/rfc4739.txt- This document specifies an extension to IKEv2 that allows the use of
../data/rfc/rfc4739.txt- multiple authentication exchanges, using either different mechanisms
../data/rfc/rfc4739.txt- or the same mechanism. This extension allows, for instance,
--
../data/rfc/rfc8426.txt- suited for SR and need to coexist with RSVP-TE in the same network.
../data/rfc/rfc8426.txt- Such introduction or migration of traffic to SR might require
../data/rfc/rfc8426.txt- coexistence with RSVP-TE in the same network for an extended period
../data/rfc/rfc8426.txt- of time, depending on the operator's intent. The following document
../data/rfc/rfc8426.txt- provides solution options for keeping the traffic engineering
../data/rfc/rfc8426.txt: database consistent across the network, accounting for the different
../data/rfc/rfc8426.txt- bandwidth utilization between SR and RSVP-TE.
../data/rfc/rfc8426.txt-
../data/rfc/rfc8426.txt-Status of This Memo
../data/rfc/rfc8426.txt-
../data/rfc/rfc8426.txt- This document is not an Internet Standards Track specification; it is
--
../data/rfc/rfc8426.txt- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
../data/rfc/rfc8426.txt-
../data/rfc/rfc8426.txt-1. Introduction
../data/rfc/rfc8426.txt-
../data/rfc/rfc8426.txt- Introduction of SR [RFC8402] in the same network domain as RSVP-TE
../data/rfc/rfc8426.txt: [RFC3209] presents the problem of accounting for SR traffic and
../data/rfc/rfc8426.txt- making RSVP-TE aware of the actual available bandwidth on the network
../data/rfc/rfc8426.txt- links. RSVP-TE is not aware of how much bandwidth is being consumed
../data/rfc/rfc8426.txt- by SR services on the network links; hence, both at computation time
../data/rfc/rfc8426.txt- (for a distributed computation) and at signaling time, RSVP-TE LSPs
../data/rfc/rfc8426.txt- will incorrectly place loads. This is true where RSVP-TE paths are
--
../data/rfc/rfc8426.txt- aware of the SR traffic reservations. In this approach, non-SR
../data/rfc/rfc8426.txt- traffic MUST NOT take the SR-dedicated RSVP-TE LSPs, unless required
../data/rfc/rfc8426.txt- by policy.
../data/rfc/rfc8426.txt-
../data/rfc/rfc8426.txt- The drawback of this solution is that it requires SR to rely on RSVP-
../data/rfc/rfc8426.txt: TE for deployment. Furthermore, the accounting accuracy/frequency of
../data/rfc/rfc8426.txt- this method is dependent on performance of auto-bandwidth for RSVP-
../data/rfc/rfc8426.txt- TE. Note that, for this method to work, the SR-dedicated RSVP-TE
../data/rfc/rfc8426.txt- LSPs must be set up with the best setup and hold priorities in the
../data/rfc/rfc8426.txt- network.
../data/rfc/rfc8426.txt-
--
../data/rfc/rfc7660.txt- does not provide specific actions when the flow(s) described by the
../data/rfc/rfc7660.txt- Filter-Rule are congested.
../data/rfc/rfc7660.txt-
../data/rfc/rfc7660.txt- Further, a Filter-Rule can describe multiple flows but not the exact
../data/rfc/rfc7660.txt- number of flows. Flow count and other associated data (e.g.,
../data/rfc/rfc7660.txt: packets) are not captured by accounting applications, leaving
../data/rfc/rfc7660.txt- administrators without useful information regarding the effectiveness
../data/rfc/rfc7660.txt- or appropriateness of the filter definition.
../data/rfc/rfc7660.txt-
../data/rfc/rfc7660.txt- The optional attributes defined in this document are forward and
../data/rfc/rfc7660.txt- backwards compatible with RFC 5777.
--
../data/rfc/rfc7660.txt- RFC 5777. As these are extensions to RFC 5777, they do not raise new
../data/rfc/rfc7660.txt- security concerns.
../data/rfc/rfc7660.txt-
../data/rfc/rfc7660.txt- The Flow-Count and Packet-Count AVPs can be provided in conjunction
../data/rfc/rfc7660.txt- with customary AVPs, e.g., Bytes, Time, Service units, during
../data/rfc/rfc7660.txt: accounting activities as described in the base protocol [RFC6733] or
../data/rfc/rfc7660.txt- other Diameter applications. These new AVPs provide more information
../data/rfc/rfc7660.txt- that can be privacy sensitive. The privacy sensitivity is directly
../data/rfc/rfc7660.txt- related to traffic captured by filters and associated reports.
../data/rfc/rfc7660.txt- Narrow filtering, which creates the highest level of privacy
../data/rfc/rfc7660.txt- sensitivity, is too resource intensive to be widely applied on large
--
../data/rfc/rfc8907.txt- 5.4.2. Common Authentication Flows
../data/rfc/rfc8907.txt- 5.4.3. Aborting an Authentication Session
../data/rfc/rfc8907.txt- 6. Authorization
../data/rfc/rfc8907.txt- 6.1. The Authorization REQUEST Packet Body
../data/rfc/rfc8907.txt- 6.2. The Authorization REPLY Packet Body
../data/rfc/rfc8907.txt: 7. Accounting
../data/rfc/rfc8907.txt- 7.1. The Account REQUEST Packet Body
../data/rfc/rfc8907.txt: 7.2. The Accounting REPLY Packet Body
../data/rfc/rfc8907.txt- 8. Argument-Value Pairs
../data/rfc/rfc8907.txt- 8.1. Value Encoding
../data/rfc/rfc8907.txt- 8.2. Authorization Arguments
../data/rfc/rfc8907.txt: 8.3. Accounting Arguments
../data/rfc/rfc8907.txt- 9. Privilege Levels
../data/rfc/rfc8907.txt- 10. Security Considerations
../data/rfc/rfc8907.txt- 10.1. General Security of the Protocol
../data/rfc/rfc8907.txt- 10.2. Security of Authentication Sessions
../data/rfc/rfc8907.txt- 10.3. Security of Authorization Sessions
../data/rfc/rfc8907.txt: 10.4. Security of Accounting Sessions
../data/rfc/rfc8907.txt- 10.5. TACACS+ Best Practices
../data/rfc/rfc8907.txt- 10.5.1. Shared Secrets
../data/rfc/rfc8907.txt- 10.5.2. Connections and Obfuscation
../data/rfc/rfc8907.txt- 10.5.3. Authentication
../data/rfc/rfc8907.txt- 10.5.4. Authorization
--
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt-1. Introduction
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt- This document describes the Terminal Access Controller Access-Control
../data/rfc/rfc8907.txt- System Plus (TACACS+) protocol. It was conceived initially as a
../data/rfc/rfc8907.txt: general Authentication, Authorization, and Accounting (AAA) protocol.
../data/rfc/rfc8907.txt- It is widely deployed today but is mainly confined for a specific
../data/rfc/rfc8907.txt- subset of AAA called Device Administration, which includes
../data/rfc/rfc8907.txt- authenticating access to network devices, providing central
../data/rfc/rfc8907.txt- authorization of operations, and auditing of those operations.
../data/rfc/rfc8907.txt-
--
../data/rfc/rfc8907.txt- future development features, and it uses TCP to ensure reliable
../data/rfc/rfc8907.txt- delivery. The protocol allows the TACACS+ client to request fine-
../data/rfc/rfc8907.txt- grained access control and allows the server to respond to each
../data/rfc/rfc8907.txt- component of that request.
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt: The separation of authentication, authorization, and accounting is a
../data/rfc/rfc8907.txt- key element of the design of TACACS+ protocol. Essentially, it makes
../data/rfc/rfc8907.txt- TACACS+ a suite of three protocols. This document will address each
../data/rfc/rfc8907.txt- one in separate sections. Although TACACS+ defines all three, an
../data/rfc/rfc8907.txt- implementation or deployment is not required to employ all three.
../data/rfc/rfc8907.txt- Separating the elements is useful for the Device Administration use
../data/rfc/rfc8907.txt: case, specifically, for authorization and accounting of individual
../data/rfc/rfc8907.txt- commands in a session. Note that there is no provision made at the
../data/rfc/rfc8907.txt- protocol level to associate authentication requests with
../data/rfc/rfc8907.txt- authorization requests.
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt-2. Conventions
--
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt-3.5. Session
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt- The concept of a session is used throughout this document. A TACACS+
../data/rfc/rfc8907.txt- session is a single authentication sequence, a single authorization
../data/rfc/rfc8907.txt: exchange, or a single accounting exchange.
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt: An accounting and authorization session will consist of a single pair
../data/rfc/rfc8907.txt- of packets (the request and its reply). An authentication session
../data/rfc/rfc8907.txt- may involve an arbitrary number of packets being exchanged. The
../data/rfc/rfc8907.txt- session is an operational concept that is maintained between the
../data/rfc/rfc8907.txt- TACACS+ client and server. It does not necessarily correspond to a
../data/rfc/rfc8907.txt- given user or user action.
--
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt- TAC_PLUS_AUTHEN := 0x01 (Authentication)
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt- TAC_PLUS_AUTHOR := 0x02 (Authorization)
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt: TAC_PLUS_ACCT := 0x03 (Accounting)
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt- seq_no
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt- This is the sequence number of the current packet. The first
../data/rfc/rfc8907.txt- packet in a session MUST have the sequence number 1, and each
--
../data/rfc/rfc8907.txt- Connection Mode when it initiates the next session.
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt-4.4. Session Completion
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt- The REPLY packets defined for the packet types in the sections below
../data/rfc/rfc8907.txt: (Authentication, Authorization, and Accounting) contain a status
../data/rfc/rfc8907.txt- field. The complete set of options for this field depend upon the
../data/rfc/rfc8907.txt- packet type, but all three REPLY packet types define values
../data/rfc/rfc8907.txt- representing PASS, ERROR, and FAIL, which indicate the last packet of
../data/rfc/rfc8907.txt- a regular session (one that is not aborted).
../data/rfc/rfc8907.txt-
--
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt- Table 1: TACACS+ Protocol Versioning
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt- The '-' symbol represents that the option is not valid.
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt: All authorization and accounting and ASCII authentication use
../data/rfc/rfc8907.txt- minor_version 0.
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt- PAP, CHAP, and MS-CHAP login use minor_version 1. The normal
../data/rfc/rfc8907.txt- exchange is a single START packet from the client and a single REPLY
../data/rfc/rfc8907.txt- from the server.
--
../data/rfc/rfc8907.txt- This field corresponds to the authen_type field in
../data/rfc/rfc8907.txt- "Authentication" (Section 5). It indicates the type of
../data/rfc/rfc8907.txt- authentication that was performed. If this information is not
../data/rfc/rfc8907.txt- available, then the client will set authen_type to
../data/rfc/rfc8907.txt- TAC_PLUS_AUTHEN_TYPE_NOT_SET := 0x00. This value is valid only in
../data/rfc/rfc8907.txt: authorization and accounting requests.
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt- authen_service
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt- This field is the same as the authen_service field in
../data/rfc/rfc8907.txt- "Authentication" (Section 5). It indicates the service through
--
../data/rfc/rfc8907.txt- "Authorization Arguments" (Section 8.2). Each argument is encoded
../data/rfc/rfc8907.txt- in the packet as a single arg field (arg_1... arg_N) with a
../data/rfc/rfc8907.txt- corresponding length field (which indicates the length of each
../data/rfc/rfc8907.txt- argument in bytes).
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt:7. Accounting
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt: Accounting is typically the third action after authentication and
../data/rfc/rfc8907.txt- authorization. But again, neither authentication nor authorization
../data/rfc/rfc8907.txt: is required. Accounting is the action of recording what a user is
../data/rfc/rfc8907.txt: doing and/or has done. Accounting in TACACS+ can serve two purposes:
../data/rfc/rfc8907.txt- it may be used as an auditing tool for security services, and it may
../data/rfc/rfc8907.txt- also be used to account for services used such as in a billing
../data/rfc/rfc8907.txt: environment. To this end, TACACS+ supports three types of accounting
../data/rfc/rfc8907.txt- records: Start records indicate that a service is about to begin,
../data/rfc/rfc8907.txt- Stop records indicate that a service has just terminated, and Update
../data/rfc/rfc8907.txt- records are intermediate notices that indicate that a service is
../data/rfc/rfc8907.txt: still being performed. TACACS+ accounting records contain all the
../data/rfc/rfc8907.txt- information used in the authorization records and also contain
../data/rfc/rfc8907.txt: accounting-specific information such as start and stop times (when
../data/rfc/rfc8907.txt: appropriate) and resource usage information. A list of accounting
../data/rfc/rfc8907.txt: arguments is defined in "Accounting Arguments" (Section 8.3).
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt-7.1. The Account REQUEST Packet Body
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt- 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
../data/rfc/rfc8907.txt- +----------------+----------------+----------------+----------------+
--
../data/rfc/rfc8907.txt- TAC_PLUS_ACCT_FLAG_WATCHDOG := 0x08
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt- All other fields are defined in "Authentication" (Section 5) and
../data/rfc/rfc8907.txt- "Authorization" (Section 6) and have the same semantics. They
../data/rfc/rfc8907.txt- provide details for the conditions on the client, and authentication
../data/rfc/rfc8907.txt: context, so that these details may be logged for accounting purposes.
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt: See "Accounting Arguments" (Section 8.3) for the dictionary of
../data/rfc/rfc8907.txt: arguments relevant to accounting.
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt:7.2. The Accounting REPLY Packet Body
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt: The purpose of accounting is to record the action that has occurred
../data/rfc/rfc8907.txt- on the client. The server MUST reply with success only when the
../data/rfc/rfc8907.txt: accounting request has been recorded. If the server did not record
../data/rfc/rfc8907.txt: the accounting request, then it MUST reply with ERROR.
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt- 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
../data/rfc/rfc8907.txt- +----------------+----------------+----------------+----------------+
../data/rfc/rfc8907.txt- | server_msg len | data_len |
../data/rfc/rfc8907.txt- +----------------+----------------+----------------+----------------+
--
../data/rfc/rfc8907.txt- display, console, or log. The decision to present this message is
../data/rfc/rfc8907.txt- client specific. The data_len indicates the length of the data
../data/rfc/rfc8907.txt- field, in bytes. For details of text encoding, see "Treatment of
../data/rfc/rfc8907.txt- Text Strings" (Section 3.7).
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt: TACACS+ accounting is intended to record various types of events on
../data/rfc/rfc8907.txt- clients, for example: login sessions, command entry, and others as
../data/rfc/rfc8907.txt- required by the client implementation. These events are collectively
../data/rfc/rfc8907.txt- referred to in "The Draft" [THE-DRAFT] as "tasks".
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt- The TAC_PLUS_ACCT_FLAG_START flag indicates that this is a start
../data/rfc/rfc8907.txt: accounting message. Start messages will only be sent once when a
../data/rfc/rfc8907.txt- task is started. The TAC_PLUS_ACCT_FLAG_STOP indicates that this is
../data/rfc/rfc8907.txt- a stop record and that the task has terminated. The
../data/rfc/rfc8907.txt- TAC_PLUS_ACCT_FLAG_WATCHDOG flag means that this is an update record.
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt- +==========+======+=======+=============+=========================+
../data/rfc/rfc8907.txt- | Watchdog | Stop | Start | Flags & 0xE | Meaning |
../data/rfc/rfc8907.txt- +==========+======+=======+=============+=========================+
../data/rfc/rfc8907.txt- | 0 | 0 | 0 | 0 | INVALID |
../data/rfc/rfc8907.txt- +----------+------+-------+-------------+-------------------------+
../data/rfc/rfc8907.txt: | 0 | 0 | 1 | 2 | Start Accounting Record |
../data/rfc/rfc8907.txt- +----------+------+-------+-------------+-------------------------+
../data/rfc/rfc8907.txt: | 0 | 1 | 0 | 4 | Stop Accounting Record |
../data/rfc/rfc8907.txt- +----------+------+-------+-------------+-------------------------+
../data/rfc/rfc8907.txt- | 0 | 1 | 1 | 6 | INVALID |
../data/rfc/rfc8907.txt- +----------+------+-------+-------------+-------------------------+
../data/rfc/rfc8907.txt- | 1 | 0 | 0 | 8 | Watchdog, no update |
../data/rfc/rfc8907.txt- +----------+------+-------+-------------+-------------------------+
--
../data/rfc/rfc8907.txt- | 1 | 1 | 0 | C | INVALID |
../data/rfc/rfc8907.txt- +----------+------+-------+-------------+-------------------------+
../data/rfc/rfc8907.txt- | 1 | 1 | 1 | E | INVALID |
../data/rfc/rfc8907.txt- +----------+------+-------+-------------+-------------------------+
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt: Table 2: Summary of Accounting Packets
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt- The START and STOP flags are mutually exclusive.
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt- The WATCHDOG flag is used by the client to communicate ongoing status
../data/rfc/rfc8907.txt- of a long-running task. Update records are sent at the client's
--
../data/rfc/rfc8907.txt- requests an INVALID option.
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt-8. Argument-Value Pairs
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt- TACACS+ is intended to be an extensible protocol. The arguments used
../data/rfc/rfc8907.txt: in Authorization and Accounting are not limited by this document.
../data/rfc/rfc8907.txt- Some arguments are defined below for common use cases. Clients MUST
../data/rfc/rfc8907.txt- use these arguments when supporting the corresponding use cases.
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt-8.1. Value Encoding
../data/rfc/rfc8907.txt-
--
../data/rfc/rfc8907.txt-8.2. Authorization Arguments
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt- service (String)
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt- The primary service. Specifying a service argument indicates that
../data/rfc/rfc8907.txt: this is a request for authorization or accounting of that service.
../data/rfc/rfc8907.txt- For example: "shell", "tty-server", "connection", "system" and
../data/rfc/rfc8907.txt- "firewall"; others may be chosen for the required application.
../data/rfc/rfc8907.txt- This argument MUST always be included.
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt- protocol (String)
--
../data/rfc/rfc8907.txt- priv-lvl (Numeric)
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt- The privilege level to be assigned. Please refer to "Privilege
../data/rfc/rfc8907.txt- Levels" (Section 9).
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt:8.3. Accounting Arguments
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt: The following arguments are defined for TACACS+ accounting only.
../data/rfc/rfc8907.txt- They MUST precede any argument-value pairs that are defined in
../data/rfc/rfc8907.txt- "Authorization" (Section 6).
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt- task_id (String)
../data/rfc/rfc8907.txt-
--
../data/rfc/rfc8907.txt- encoding, see "Treatment of Text Strings" (Section 3.7).
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt- Where the TACACS+ deployment is used to support the Device
../data/rfc/rfc8907.txt- Administration use case, it is often required to log all commands
../data/rfc/rfc8907.txt- entered into client devices. To support this mode of operation,
../data/rfc/rfc8907.txt: TACACS+ client devices MUST be configured to send an accounting start
../data/rfc/rfc8907.txt- packet for every command entered, irrespective of how the commands
../data/rfc/rfc8907.txt: were authorized. These "Command Accounting" packets MUST include the
../data/rfc/rfc8907.txt- "service" and "cmd" arguments, and if needed, the "cmd-arg" arguments
../data/rfc/rfc8907.txt- detailed in Section 8.2.
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt-9. Privilege Levels
../data/rfc/rfc8907.txt-
--
../data/rfc/rfc8907.txt- "The Draft" [THE-DRAFT] from 1998 did not address all of the key
../data/rfc/rfc8907.txt- security concerns that are considered when designing modern
../data/rfc/rfc8907.txt- standards. This section addresses known limitations and concerns
../data/rfc/rfc8907.txt- that will impact overall security of the protocol and systems where
../data/rfc/rfc8907.txt- this protocol is deployed to manage central authentication,
../data/rfc/rfc8907.txt: authorization, or accounting for network Device Administration.
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt- Multiple implementations of the protocol described in "The Draft"
../data/rfc/rfc8907.txt- [THE-DRAFT] have been deployed. As the protocol was never
../data/rfc/rfc8907.txt- standardized, current implementations may be incompatible in non-
../data/rfc/rfc8907.txt- obvious ways, giving rise to additional security risks. This section
--
../data/rfc/rfc8907.txt- provide no meaningful integrity, privacy, or replay protection. An
../data/rfc/rfc8907.txt- attacker with access to the data stream should be assumed to be able
../data/rfc/rfc8907.txt- to read and modify all TACACS+ packets. Without mitigation, a range
../data/rfc/rfc8907.txt- of risks such as the following are possible:
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt: * Accounting information may be modified by the man-in-the-middle
../data/rfc/rfc8907.txt- attacker, making such logs unsuitable and not trustable for
../data/rfc/rfc8907.txt- auditing purposes.
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt- * Invalid or misleading values may be inserted by the man-in-the-
../data/rfc/rfc8907.txt- middle attacker in various fields at known offsets to try and
--
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt- * In combination with known plaintext, the attacker can determine
../data/rfc/rfc8907.txt- with certainty the value of the crypto-pad octet used to obfuscate
../data/rfc/rfc8907.txt- the original octet.
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt:10.4. Security of Accounting Sessions
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt: Accounting sessions SHOULD be used via a secure transport (see
../data/rfc/rfc8907.txt: "TACACS+ Best Practices" (Section 10.5)). Although Accounting
../data/rfc/rfc8907.txt- sessions are not directly involved in authentication or authorizing
../data/rfc/rfc8907.txt- operations on the device, man-in-the-middle attackers may do any of
../data/rfc/rfc8907.txt- the following:
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt: * Replace accounting data with new valid values or garbage that can
../data/rfc/rfc8907.txt- confuse auditors or hide information related to their
../data/rfc/rfc8907.txt- authentication and/or authorization attack attempts.
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt: * Try and poison an accounting log with entries designed to make
../data/rfc/rfc8907.txt- systems behave in unintended ways (these systems could be TACACS+
../data/rfc/rfc8907.txt: servers and any other systems that would manage accounting
../data/rfc/rfc8907.txt- entries).
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt- In addition to these direct manipulations, different client
../data/rfc/rfc8907.txt: implementations pass a different fidelity of accounting data. Some
../data/rfc/rfc8907.txt- vendors have been observed in the wild that pass sensitive data like
../data/rfc/rfc8907.txt: passwords, encryption keys, and the like as part of the accounting
../data/rfc/rfc8907.txt- log. Due to a lack of strong encryption with perfect forward
../data/rfc/rfc8907.txt- secrecy, this data may be revealed in the future, leading to a
../data/rfc/rfc8907.txt- security incident.
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt-10.5. TACACS+ Best Practices
--
../data/rfc/rfc8907.txt- disabled and MUST warn the administrator that these options are not
../data/rfc/rfc8907.txt- secure.
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt-10.5.4. Authorization
../data/rfc/rfc8907.txt-
../data/rfc/rfc8907.txt: The authorization and accounting features are intended to provide
../data/rfc/rfc8907.txt- extensibility and flexibility. There is a base dictionary defined in
../data/rfc/rfc8907.txt- this document, but it may be extended in deployments by using new
../data/rfc/rfc8907.txt- argument names. The cost of the flexibility is that administrators
../data/rfc/rfc8907.txt- and implementers MUST ensure that the argument and value pairs shared
../data/rfc/rfc8907.txt- between the clients and servers have consistent interpretation.
--
../data/rfc/rfc7056.txt-
../data/rfc/rfc7056.txt- The naming extensions to the Generic Security Service Application
../data/rfc/rfc7056.txt- Programming Interface (GSS-API) provide a mechanism for applications
../data/rfc/rfc7056.txt- to discover authorization and personalization information associated
../data/rfc/rfc7056.txt- with GSS-API names. The Extensible Authentication Protocol GSS-API
../data/rfc/rfc7056.txt: mechanism allows an Authentication, Authorization, and Accounting
../data/rfc/rfc7056.txt- (AAA) peer to provide authorization attributes alongside an
../data/rfc/rfc7056.txt- authentication response. It also supplies mechanisms to process
../data/rfc/rfc7056.txt- Security Assertion Markup Language (SAML) messages provided in the
../data/rfc/rfc7056.txt- AAA response. This document describes how to use the Naming
../data/rfc/rfc7056.txt- Extensions API to access that information.
--
../data/rfc/rfc7056.txt- The naming extensions [RFC6680] to the Generic Security Service
../data/rfc/rfc7056.txt- Application Programming Interface (GSS-API) [RFC2743] provide a
../data/rfc/rfc7056.txt- mechanism for applications to discover authorization and
../data/rfc/rfc7056.txt- personalization information associated with GSS-API names. The
../data/rfc/rfc7056.txt- Extensible Authentication Protocol GSS-API mechanism [RFC7055] allows
../data/rfc/rfc7056.txt: an Authentication, Authorization, and Accounting (AAA) peer to
../data/rfc/rfc7056.txt- provide authorization attributes alongside an authentication
../data/rfc/rfc7056.txt- response. It also supplies mechanisms to process Security Assertion
../data/rfc/rfc7056.txt- Markup Language (SAML) messages provided in the AAA response. Other
../data/rfc/rfc7056.txt- mechanisms such as SAML Enhanced Client (EC) [SASL-SAML] also support
../data/rfc/rfc7056.txt- SAML assertions and attributes carried in the GSS-API. This document
--
../data/rfc/rfc6467.txt-
../data/rfc/rfc6467.txt- The secure password methods are not usually meant to be used in the
../data/rfc/rfc6467.txt- normal end user (remote access VPN) cases. In such cases, EAP-based
../data/rfc/rfc6467.txt- authentication works fine, and the asymmetric nature of EAP does not
../data/rfc/rfc6467.txt- matter. In such scenarios, the authentication is usually backed up
../data/rfc/rfc6467.txt: with the back-end Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc6467.txt- servers and other infrastructure. That is, in such scenarios,
../data/rfc/rfc6467.txt- neither of the IKEv2 peers really knows the secret, as on one end it
../data/rfc/rfc6467.txt- is typed in by the user when it is needed, and on the other end it is
../data/rfc/rfc6467.txt- authenticated by the back-end AAA server.
../data/rfc/rfc6467.txt-
--
../data/rfc/rfc1689.txt- Program priorities are 1) to facilitate a consistent and complete
../data/rfc/rfc1689.txt- mechanism for linking bibliographic, abstracting, and indexing files
../data/rfc/rfc1689.txt- to files of their associated source materials; 2) a single standard
../data/rfc/rfc1689.txt- for the transmission of bitmapped image files; 3) protocols for
../data/rfc/rfc1689.txt- handling networked requests for delivery of source materials; 4)
../data/rfc/rfc1689.txt: mechanisms for interorganizational authentication, accounting, and
../data/rfc/rfc1689.txt- billing; and 5) to integrate lessons drawn from the experience of
../data/rfc/rfc1689.txt- pilot projects that exercise networked printing utilities and 6) to
../data/rfc/rfc1689.txt- provide an "interoperability workshop" to specify, implement, and
../data/rfc/rfc1689.txt- test advanced functions of Z39.50 to accelerate the pace and to
../data/rfc/rfc1689.txt- ensure the quality of standardization efforts in this area.
--
../data/rfc/rfc1689.txt- Program priorities are 1) to facilitate a consistent and complete
../data/rfc/rfc1689.txt- mechanism for linking bibliographic, abstracting, and indexing files
../data/rfc/rfc1689.txt- to files of their associated source materials; 2) a single standard
../data/rfc/rfc1689.txt- for the transmission of bitmapped image files; 3) protocols for
../data/rfc/rfc1689.txt- handing networked requests for delivery of source materials; 4)
../data/rfc/rfc1689.txt: mechanisms for interorganizational authentication, accounting, and
../data/rfc/rfc1689.txt- billing; and 5) to integrate lessons drawn from the experience of
../data/rfc/rfc1689.txt- pilot projects that exercise networked printing utilities and 6) to
../data/rfc/rfc1689.txt- provide an "interoperability workshop" to specify, implement, and test
../data/rfc/rfc1689.txt- advanced functions of Z39.50 to accelerate the pace and to ensure the
../data/rfc/rfc1689.txt- quality of standardization efforts in this area.
--
../data/rfc/rfc7336.txt- environment (without CDNI), the CSP places a degree of trust in a
../data/rfc/rfc7336.txt- single CDN operator to perform many functions. The CDN is trusted to
../data/rfc/rfc7336.txt- deliver content with appropriate quality of experience for the end
../data/rfc/rfc7336.txt- user. The CSP trusts the CDN operator not to corrupt or modify the
../data/rfc/rfc7336.txt- content. The CSP often relies on the CDN operator to provide
../data/rfc/rfc7336.txt: reliable accounting information regarding the volume of delivered
../data/rfc/rfc7336.txt- content. The CSP may also trust the CDN operator to perform actions
../data/rfc/rfc7336.txt- such as timely invalidation of content and restriction of access to
../data/rfc/rfc7336.txt- content based on certain criteria such as location of the user and
../data/rfc/rfc7336.txt- time of day, and to enforce per-request authorization performed by
../data/rfc/rfc7336.txt- the CSP using techniques such as URI signing.
--
../data/rfc/rfc7336.txt- CSP will in some cases take steps to protect its content from
../data/rfc/rfc7336.txt- improper distribution by a CDN, e.g., by encrypting it and
../data/rfc/rfc7336.txt- distributing keys in some out of band way. A CSP also depends on
../data/rfc/rfc7336.txt- monitoring (possibly by third parties) and reporting to verify that
../data/rfc/rfc7336.txt- the CDN has performed adequately. A CSP may use techniques such as
../data/rfc/rfc7336.txt: client-based metering to verify that accounting information provided
../data/rfc/rfc7336.txt- by the CDN is reliable. HTTP conditional requests may be used to
../data/rfc/rfc7336.txt- provide the CSP with some checks on CDN operation. In other words,
../data/rfc/rfc7336.txt- while a CSP may trust a CDN to perform some functions in the short
../data/rfc/rfc7336.txt- term, the CSP is able, in most cases, to verify whether these actions
../data/rfc/rfc7336.txt- have been performed correctly and to take action (such as moving the
--
../data/rfc/rfc8157.txt-
../data/rfc/rfc8157.txt- CIR: Committed Information Rate [RFC2697].
../data/rfc/rfc8157.txt-
../data/rfc/rfc8157.txt- RTT: Round-Trip Time.
../data/rfc/rfc8157.txt-
../data/rfc/rfc8157.txt: AAA: Authentication, Authorization, and Accounting [RFC6733].
../data/rfc/rfc8157.txt-
../data/rfc/rfc8157.txt- SOAP: Simple Object Access Protocol. A protocol specification for
../data/rfc/rfc8157.txt- exchanging structured information in the implementation of web
../data/rfc/rfc8157.txt- services in computer networks.
../data/rfc/rfc8157.txt-
--
../data/rfc/rfc4110.txt- that is not going to or coming from those sites.
../data/rfc/rfc4110.txt-
../data/rfc/rfc4110.txt- Virtual Router (VR): An instance of one of a number of logical
../data/rfc/rfc4110.txt- routers located within a single physical router. Each logical router
../data/rfc/rfc4110.txt- emulates a physical router using existing mechanisms and tools for
../data/rfc/rfc4110.txt: configuration, operation, accounting, and maintenance.
../data/rfc/rfc4110.txt-
../data/rfc/rfc4110.txt- VPN Forwarding Instance (VFI): A logical entity that resides in a PE
../data/rfc/rfc4110.txt- that includes the router information base and forwarding information
../data/rfc/rfc4110.txt- base for a VPN.
../data/rfc/rfc4110.txt-
--
../data/rfc/rfc4110.txt- for using a partial mesh topology is to reduce the number of tunnels
../data/rfc/rfc4110.txt- a VPN edge device, and/or the network, needs to support. Another
../data/rfc/rfc4110.txt- reason is to support the scenario where an administrator requires all
../data/rfc/rfc4110.txt- traffic from certain sites to traverse some particular site for
../data/rfc/rfc4110.txt- policy or control reasons, such as to force traffic through a
../data/rfc/rfc4110.txt: firewall, or for monitoring or accounting purposes. Note that the
../data/rfc/rfc4110.txt- topologies used for each VPN are separate, and thus the same VPN edge
../data/rfc/rfc4110.txt- device may be part of a full mesh topology for one VPN, and of a
../data/rfc/rfc4110.txt- partial mesh topology for another VPN.
../data/rfc/rfc4110.txt-
../data/rfc/rfc4110.txt- An example of where a partial mesh topology could be suitable is for
--
../data/rfc/rfc4044.txt-
../data/rfc/rfc4044.txt-13. Comparison to RFC 2837
../data/rfc/rfc4044.txt-
../data/rfc/rfc4044.txt- This MIB is a superset of RFC 2837, except for the following:
../data/rfc/rfc4044.txt-
../data/rfc/rfc4044.txt: - the fcFeClass1AccountingGroup group is obsolete,
../data/rfc/rfc4044.txt-
../data/rfc/rfc4044.txt- - fcFxPortConnectedNxPort, fcFxPortFcphVersionHigh,
../data/rfc/rfc4044.txt- fcFxPortFcphVersionLow, fcFxPortFcphVersionAgreed,
../data/rfc/rfc4044.txt- fcFxPortStackedConnModeAgreed, fcFxPortIntermixSuppAgreed,
../data/rfc/rfc4044.txt- fcFxPortCapStackedConnMode, and fcFxPortCapIntermix are obsolete,
--
../data/rfc/rfc6043.txt- | OR (selection operator)
../data/rfc/rfc6043.txt-
../data/rfc/rfc6043.txt-2.2. Abbreviations
../data/rfc/rfc6043.txt-
../data/rfc/rfc6043.txt- 3GPP: 3rd Generation Partnership Project
../data/rfc/rfc6043.txt: AAA: Authentication, Authorization, and Accounting
../data/rfc/rfc6043.txt- ACL: Access Control List
../data/rfc/rfc6043.txt- AES: Advanced Encryption Standard
../data/rfc/rfc6043.txt- CA: Certification Authority
../data/rfc/rfc6043.txt- CS: Crypto Session
../data/rfc/rfc6043.txt- CSB: Crypto Session Bundle
--
../data/rfc/rfc6043.txt- At the same time, it is also important to be aware that (centralized)
../data/rfc/rfc6043.txt- key management services may introduce a single point of (security)
../data/rfc/rfc6043.txt- failure. The security requirements on the implementation and
../data/rfc/rfc6043.txt- protection of the KMS may therefore, in high-security applications,
../data/rfc/rfc6043.txt- be more or less equivalent to the requirements of an AAA
../data/rfc/rfc6043.txt: (Authentication, Authorization, and Accounting) server or a
../data/rfc/rfc6043.txt- Certification Authority (CA).
../data/rfc/rfc6043.txt-
../data/rfc/rfc6043.txt-4. MIKEY-TICKET
../data/rfc/rfc6043.txt-
../data/rfc/rfc6043.txt-4.1. Overview
--
../data/rfc/rfc5419.txt- MN and HA. So the alternate solution is in addition to the IPsec-
../data/rfc/rfc5419.txt- based mechanism specified in the base RFCs, i.e., [RFC3775],
../data/rfc/rfc5419.txt- [RFC3776], and [RFC4877]. It has been noted that some of the
../data/rfc/rfc5419.txt- challenges of deploying MIPv6 in certain types of networks arose from
../data/rfc/rfc5419.txt- dependence on the Internet Key Exchange (IKE), which did not
../data/rfc/rfc5419.txt: integrate well with an Authentication, Authorization, and Accounting
../data/rfc/rfc5419.txt- (AAA) backend infrastructure. IKEv2 solves this problem. However,
../data/rfc/rfc5419.txt- at the time of discussion on the need for the authentication
../data/rfc/rfc5419.txt-
../data/rfc/rfc5419.txt-
../data/rfc/rfc5419.txt-
--
../data/rfc/rfc5419.txt- WiMAX networks. CDMA2000 networks are currently deployed in many
../data/rfc/rfc5419.txt- countries today. WiMAX deployments in many countries began in 2008.
../data/rfc/rfc5419.txt- The packet data network architecture of CDMA2000 [3GPP2
../data/rfc/rfc5419.txt- X.S0011-002-D] includes a MIPv4 foreign agent/home agent and a
../data/rfc/rfc5419.txt- RADIUS-based AAA infrastructure for Authentication, Authorization,
../data/rfc/rfc5419.txt: and Accounting purposes. The AAA infrastructure provides
../data/rfc/rfc5419.txt- authentication capability in the case of Mobile IPv4.
../data/rfc/rfc5419.txt-
../data/rfc/rfc5419.txt- Typically, the mobile node shares a security association with the
../data/rfc/rfc5419.txt- AAA-Home entity. This is the preferred mode of operation over having
../data/rfc/rfc5419.txt- a shared secret between the MN and HA because the AAA-Home entity
--
../data/rfc/rfc5419.txt- of attachment. While route optimization negates the benefit of
../data/rfc/rfc5419.txt- having a home agent on a link close to the MN, it cannot always be
../data/rfc/rfc5419.txt- guaranteed that the MN and correspondent node (CN) will use or
../data/rfc/rfc5419.txt- support route optimization. There may also be instances where the
../data/rfc/rfc5419.txt- operator prefers to not allow route optimization for various reasons,
../data/rfc/rfc5419.txt: such as accounting aggregation or enforcing service contracts. In
../data/rfc/rfc5419.txt- such cases, an HA that is close to the MN's point of attachment
../data/rfc/rfc5419.txt- reduces the issues of latency, etc. of forward and reverse tunnelling
../data/rfc/rfc5419.txt- of packets between the MN and HA.
../data/rfc/rfc5419.txt-
../data/rfc/rfc5419.txt- CDMA2000 networks that are operational today have large numbers of
--
../data/rfc/rfc5419.txt- - Authenticating signaling messages other than BU/BAck
../data/rfc/rfc5419.txt- between the MN and HA, such as ICMPv6, MLD, and DHCPv6.
../data/rfc/rfc5419.txt-
../data/rfc/rfc5419.txt- - Enforcing access control to the network behind the HA.
../data/rfc/rfc5419.txt-
../data/rfc/rfc5419.txt: - Accounting or other flow-specific processing performed by
../data/rfc/rfc5419.txt- the HA.
../data/rfc/rfc5419.txt-
../data/rfc/rfc5419.txt- This means the authentication option is of limited
../data/rfc/rfc5419.txt- applicability in environments where the HA can receive
../data/rfc/rfc5419.txt- reverse-tunneled packets with spoofed source IP addresses
--
../data/rfc/rfc5419.txt- [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H.
../data/rfc/rfc5419.txt- Soliman, "Neighbor Discovery for IP version 6
../data/rfc/rfc5419.txt- (IPv6)", RFC 4861, September 2007.
../data/rfc/rfc5419.txt-
../data/rfc/rfc5419.txt- [RFC3957] Perkins, C. and P. Calhoun, "Authentication,
../data/rfc/rfc5419.txt: Authorization, and Accounting (AAA)
../data/rfc/rfc5419.txt- Registration Keys for Mobile IPv4", RFC 3957,
../data/rfc/rfc5419.txt- March 2005.
../data/rfc/rfc5419.txt-
../data/rfc/rfc5419.txt- [RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H.,
../data/rfc/rfc5419.txt- and K. Chowdhury, "Authentication Protocol for
--
../data/rfc/rfc8802.txt- * A BEGIN message has been received by the server. The pre-existing
../data/rfc/rfc8802.txt- Q4S quality session is canceled, and a new session will be
../data/rfc/rfc8802.txt- initiated.
../data/rfc/rfc8802.txt-
../data/rfc/rfc8802.txt- The meaning of the Termination phase in terms of the release of
../data/rfc/rfc8802.txt: resources or accounting is application dependent and out of scope of
../data/rfc/rfc8802.txt- the Q4S protocol.
../data/rfc/rfc8802.txt-
../data/rfc/rfc8802.txt- In the Reactive alerting mode, Q4S CANCEL messages received by the
../data/rfc/rfc8802.txt- Q4S server must cause the server stack to send cancel notifications
../data/rfc/rfc8802.txt- to the Actuator in order to release possible assigned resources for
--
../data/rfc/rfc7589.txt- used to issue certificates for other purposes, then all certificates
../data/rfc/rfc7589.txt- created for other purposes will be accepted by a NETCONF server as
../data/rfc/rfc7589.txt- well, which is likely not suitable.
../data/rfc/rfc7589.txt-
../data/rfc/rfc7589.txt- This document does not support third-party authentication (e.g.,
../data/rfc/rfc7589.txt: backend Authentication, Authorization, and Accounting (AAA) servers)
../data/rfc/rfc7589.txt- due to the fact that TLS does not specify this way of authentication
../data/rfc/rfc7589.txt- and that NETCONF depends on the transport protocol for the
../data/rfc/rfc7589.txt- authentication service. If third-party authentication is needed, the
../data/rfc/rfc7589.txt- Secure Shell (SSH) transport [RFC6242] can be used.
../data/rfc/rfc7589.txt-
--
../data/rfc/rfc3573.txt- others.
../data/rfc/rfc3573.txt-
../data/rfc/rfc3573.txt- * Temporarily stop polling protocols such as LCP Echo Requests, Link
../data/rfc/rfc3573.txt- Quality Monitoring (LQM), Multilink PPP (MP), etc.
../data/rfc/rfc3573.txt- * Drop data packets directed to the now on-hold remote client.
../data/rfc/rfc3573.txt: * Start a new accounting session, to account for the on-hold time.
../data/rfc/rfc3573.txt: * Stop or hold accounting until the modem returns online again.
../data/rfc/rfc3573.txt: * Start a separate time accounting for the time that the modem is on
../data/rfc/rfc3573.txt- hold.
../data/rfc/rfc3573.txt-
../data/rfc/rfc3573.txt- Here are a few things that an LNS should probably NOT do:
../data/rfc/rfc3573.txt-
../data/rfc/rfc3573.txt- * Buffer data packets directed to the now on-hold remote client.
--
../data/rfc/rfc3076.txt-RFC 3076 Canonical XML March 2001
../data/rfc/rfc3076.txt-
../data/rfc/rfc3076.txt-
../data/rfc/rfc3076.txt- whitespace and equivalent data (e.g., <color>black</color> versus
../data/rfc/rfc3076.txt- <color>rgb(0,0,0)</color>). There are also equivalencies established
../data/rfc/rfc3076.txt: by other W3C Recommendations and Working Drafts. Accounting for
../data/rfc/rfc3076.txt- these additional equivalence rules is beyond the scope of this work.
../data/rfc/rfc3076.txt- They can be applied by the application or become the subject of
../data/rfc/rfc3076.txt- future specifications.
../data/rfc/rfc3076.txt-
../data/rfc/rfc3076.txt- The canonical form of an XML document may not be completely
--
../data/rfc/rfc3290.txt-3.1.2. Configuration and Management Interface
../data/rfc/rfc3290.txt-
../data/rfc/rfc3290.txt- Diffserv operating parameters are monitored and provisioned through
../data/rfc/rfc3290.txt- this interface. Monitored parameters include statistics regarding
../data/rfc/rfc3290.txt- traffic carried at various Diffserv service levels. These statistics
../data/rfc/rfc3290.txt: may be important for accounting purposes and/or for tracking
../data/rfc/rfc3290.txt- compliance to Traffic Conditioning Specifications (TCSs) negotiated
../data/rfc/rfc3290.txt- with customers. Provisioned parameters are primarily the TCS
../data/rfc/rfc3290.txt- parameters for Classifiers and Meters and the associated PHB
../data/rfc/rfc3290.txt- configuration parameters for Actions and Queuing elements. The
../data/rfc/rfc3290.txt- network administrator interacts with the Diffserv configuration and
--
../data/rfc/rfc4097.txt- Diameter is designed to support AAA for network access. It is meant
../data/rfc/rfc4097.txt- to operate through networks of Diameter nodes, which both act upon
../data/rfc/rfc4097.txt- and route messages toward their final destinations. Endpoints are
../data/rfc/rfc4097.txt- characterized as either clients, which perform network access
../data/rfc/rfc4097.txt- control, or servers, which handle authentication, authorization and
../data/rfc/rfc4097.txt: accounting requests for a particular realm. Intermediate nodes
../data/rfc/rfc4097.txt- perform relay, proxy, redirect, and translation services. Design
../data/rfc/rfc4097.txt-
../data/rfc/rfc4097.txt-
../data/rfc/rfc4097.txt-
../data/rfc/rfc4097.txt-Barnes Informational [Page 8]
--
../data/rfc/rfc2635.txt-Hambridge & Lunde Informational [Page 1]
../data/rfc/rfc2635.txt-
../data/rfc/rfc2635.txt-RFC 2635 DON'T SPEW June 1999
../data/rfc/rfc2635.txt-
../data/rfc/rfc2635.txt-
../data/rfc/rfc2635.txt: driver code on the Internet. There is no end-to-end cost accounting
../data/rfc/rfc2635.txt- and/or cost recovery. Bandwidth is shared among all traffic without
../data/rfc/rfc2635.txt- resource reservation (although this is changing).
../data/rfc/rfc2635.txt-
../data/rfc/rfc2635.txt- Unfortunately for all of us, the culture so carefully nurtured
../data/rfc/rfc2635.txt- through the early years of the Internet was not fully transferred to
--
../data/rfc/rfc6550.txt-18. Manageability Considerations
../data/rfc/rfc6550.txt-
../data/rfc/rfc6550.txt- The aim of this section is to give consideration to the manageability
../data/rfc/rfc6550.txt- of RPL, and how RPL will be operated in an LLN. The scope of this
../data/rfc/rfc6550.txt- section is to consider the following aspects of manageability:
../data/rfc/rfc6550.txt: configuration, monitoring, fault management, accounting, and
../data/rfc/rfc6550.txt- performance of the protocol in light of the recommendations set forth
../data/rfc/rfc6550.txt- in [RFC5706].
../data/rfc/rfc6550.txt-
../data/rfc/rfc6550.txt-
../data/rfc/rfc6550.txt-
--
../data/rfc/rfc7298.txt-
../data/rfc/rfc7298.txt-RFC 7298 Babel HMAC Cryptographic Authentication July 2014
../data/rfc/rfc7298.txt-
../data/rfc/rfc7298.txt-
../data/rfc/rfc7298.txt- [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
../data/rfc/rfc7298.txt: Authorization, and Accounting (AAA) Key Management",
../data/rfc/rfc7298.txt- BCP 132, RFC 4962, July 2007.
../data/rfc/rfc7298.txt-
../data/rfc/rfc7298.txt- [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
../data/rfc/rfc7298.txt- Aboba, "Dynamic Authorization Extensions to Remote
../data/rfc/rfc7298.txt- Authentication Dial In User Service (RADIUS)", RFC 5176,
--
../data/rfc/rfc1686.txt- 3.7 Flows and resource reservation ........................... 8
../data/rfc/rfc1686.txt- 3.8 Policy based routing ..................................... 10
../data/rfc/rfc1686.txt- 3.9 Topological flexibility .................................. 10
../data/rfc/rfc1686.txt- 3.10 Applicability ............................................ 10
../data/rfc/rfc1686.txt- 3.11 Datagram service ......................................... 11
../data/rfc/rfc1686.txt: 3.12 Accounting ............................................... 11
../data/rfc/rfc1686.txt- 3.13 Support of communication media ........................... 12
../data/rfc/rfc1686.txt- 3.14 Robustness and fault tolerance ........................... 12
../data/rfc/rfc1686.txt- 3.15 Technology pull .......................................... 12
../data/rfc/rfc1686.txt- 3.16 Action items ............................................. 13
../data/rfc/rfc1686.txt- 4. Security Considerations .................................... 13
--
../data/rfc/rfc1686.txt- resource reservation or flows. The datagram paradigm could still
../data/rfc/rfc1686.txt- be the basic service provided by IPng for many applications, but
../data/rfc/rfc1686.txt- careful thought should be given to the need to support real-time
../data/rfc/rfc1686.txt- traffic with (soft and/or hard) quality of service requirements.
../data/rfc/rfc1686.txt-
../data/rfc/rfc1686.txt: 3.12 Accounting
../data/rfc/rfc1686.txt-
../data/rfc/rfc1686.txt: The ability to do accounting should be an important consideration
../data/rfc/rfc1686.txt- in the selection of IPng. The future broadband networks will be
../data/rfc/rfc1686.txt- commercially motivated, and measurement of resource usage by the
../data/rfc/rfc1686.txt- various users will be required. The actual billing may or may not
../data/rfc/rfc1686.txt: be based on session-by-session usage, and accounting will have
../data/rfc/rfc1686.txt- many other useful purposes besides billing. The efficient
../data/rfc/rfc1686.txt- operation of networks depends on maintaining availability and
../data/rfc/rfc1686.txt- performance goals, including both on-line actions and long term
../data/rfc/rfc1686.txt: planning and design. Accounting information will be important on
../data/rfc/rfc1686.txt: both scores. On the other hand, the choice of providing accounting
../data/rfc/rfc1686.txt- capabilities at the IPng level should be examined with a general
../data/rfc/rfc1686.txt- criterion to introduce as little overhead as possible. Since
../data/rfc/rfc1686.txt- fields for "to", "from" and time stamp will be available for any
../data/rfc/rfc1686.txt- IPng choice, careful examination of what other parameters in IPng
../data/rfc/rfc1686.txt: could be useful to both accounting and other network functions so
../data/rfc/rfc1686.txt- as to keep IPng as lean as possible.
../data/rfc/rfc1686.txt-
../data/rfc/rfc1686.txt-
../data/rfc/rfc1686.txt-
../data/rfc/rfc1686.txt-
--
../data/rfc/rfc451.txt-whatever is most appropriate to a particular Host. This view has the
../data/rfc/rfc451.txt-additional virtue of keeping the Host "Answering Service"-equivalent
../data/rfc/rfc451.txt-processes out of the act when new protocols come along -- where by
../data/rfc/rfc451.txt-Answering Service, I mean that process which manages logins in general
../data/rfc/rfc451.txt-for a given Host. This process is, of course, a particularly sensitive
../data/rfc/rfc451.txt:one on those systems which worry about accounting and security.
../data/rfc/rfc451.txt-
../data/rfc/rfc451.txt-That's all probably a bit vague. Perhaps some idea of how I think the
../data/rfc/rfc451.txt-UULP would work will cast some light on what I think it is. What's
../data/rfc/rfc451.txt-needed is a way of letting the Server know that it's being given a
../data/rfc/rfc451.txt-generic command (I decline to call it a Network Virtual command, but I'm
--
../data/rfc/rfc77.txt- papers on such a protocol. A meeting may be held between the authors
../data/rfc/rfc77.txt- of such papers if sufficient interest develops. The papers should be
../data/rfc/rfc77.txt- distributed as NWG/RFC's before 1 January 71.
../data/rfc/rfc77.txt-
../data/rfc/rfc77.txt-6) Some sites must account for use of their computer resources, thus
../data/rfc/rfc77.txt: there must be some network accounting scheme. Sites can be
../data/rfc/rfc77.txt- categorized as Research Centers vs. Service Centers. The Service
../data/rfc/rfc77.txt: centers tend to have big machines, lots of users, and accounting
../data/rfc/rfc77.txt- problems; while the Research Centers tend to have specialized
../data/rfc/rfc77.txt: hardware, a small number of users, and no accounting at all.
../data/rfc/rfc77.txt-
../data/rfc/rfc77.txt-
../data/rfc/rfc77.txt-
../data/rfc/rfc77.txt-
../data/rfc/rfc77.txt-J. Postel [Page 1]
--
../data/rfc/rfc1528.txt-
../data/rfc/rfc1528.txt- o determining which content-types and character sets are
../data/rfc/rfc1528.txt- supported by a remote printer server;
../data/rfc/rfc1528.txt-
../data/rfc/rfc1528.txt- o introduction of authentication, integrity, privacy,
../data/rfc/rfc1528.txt: authorization, and accounting services;
../data/rfc/rfc1528.txt-
../data/rfc/rfc1528.txt- o preferential selection of a remote printer server; and,
../data/rfc/rfc1528.txt-
../data/rfc/rfc1528.txt- o aggregation of multiple print recipients in a single
../data/rfc/rfc1528.txt- message.
--
../data/rfc/rfc3060.txt- queue.
../data/rfc/rfc3060.txt-
../data/rfc/rfc3060.txt- o Security Policies deal with verifying that the client is actually
../data/rfc/rfc3060.txt- who the client purports to be, permitting or denying access to
../data/rfc/rfc3060.txt- resources, selecting and applying appropriate authentication
../data/rfc/rfc3060.txt: mechanisms, and performing accounting and auditing of resources.
../data/rfc/rfc3060.txt-
../data/rfc/rfc3060.txt- o Service Policies characterize network and other services (not use
../data/rfc/rfc3060.txt- them). For example, all wide-area backbone interfaces shall use a
../data/rfc/rfc3060.txt- specific type of queuing.
../data/rfc/rfc3060.txt-
--
../data/rfc/rfc871.txt- based on equity was employed. The classic example had to do with
../data/rfc/rfc871.txt- "electronic mail", where a desire to avoid charging for incoming
../data/rfc/rfc871.txt- mail led some FTP designers to think that the optionally
../data/rfc/rfc871.txt- mandatory "login" commands of the protocol shouldn't be mandatory
../data/rfc/rfc871.txt- after all. But the commands were needed by some operating
../data/rfc/rfc871.txt: systems to actuate not only accounting mechanisms but
../data/rfc/rfc871.txt- authentication mechanisms as well, and the process which
../data/rfc/rfc871.txt- "fielded" FTP connections was too privileged (and too busy) to
../data/rfc/rfc871.txt- contain the FTP PI as well. So (to make a complex story
../data/rfc/rfc871.txt- cryptic), a common name and password were advertised for a "free"
../data/rfc/rfc871.txt- account for incoming mail, and the login commands remained
--
../data/rfc/rfc4430.txt- to create and delete SAs; the security considerations which pertain
../data/rfc/rfc4430.txt- to IKE phase 1 may be safely ignored. However, being able to ignore
../data/rfc/rfc4430.txt- IKE's authentication phase necessarily means that KINK inherits all
../data/rfc/rfc4430.txt- of the security considerations of Kerberos authentication as outlined
../data/rfc/rfc4430.txt- in [KERBEROS]. For one, a KDC, like an Authentication,
../data/rfc/rfc4430.txt: Authorization, and Accounting (AAA) server, is a point of attack and
../data/rfc/rfc4430.txt- all that implies. Much has been written about various shortcomings
../data/rfc/rfc4430.txt- and mitigations of Kerberos, and they should be evaluated for any
../data/rfc/rfc4430.txt- deployment.
../data/rfc/rfc4430.txt-
../data/rfc/rfc4430.txt- KINK's use of Kerberos presents a couple of considerations. First,
--
../data/rfc/rfc2989.txt- Copyright (C) The Internet Society (2000). All Rights Reserved.
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt-Abstract
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt- This document represents a summary of Authentication, Authorization,
../data/rfc/rfc2989.txt: Accounting (AAA) protocol requirements for network access. In
../data/rfc/rfc2989.txt- creating this document, inputs were taken from documents produced by
../data/rfc/rfc2989.txt- the Network Access Server Requirements Next Generation (NASREQ),
../data/rfc/rfc2989.txt- Roaming Operations (ROAMOPS), and MOBILEIP working groups, as well as
../data/rfc/rfc2989.txt- from TIA 45.6.
../data/rfc/rfc2989.txt-
--
../data/rfc/rfc2989.txt-RFC 2989 Network Access AAA Evaluation Criteria November 2000
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt- This document summarizes the requirements collected from those
../data/rfc/rfc2989.txt- sources, separating requirements for authentication, authorization
../data/rfc/rfc2989.txt: and accounting. Details on the requirements are available in the
../data/rfc/rfc2989.txt- original documents.
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt-1. Introduction
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt- This document represents a summary of AAA protocol requirements for
../data/rfc/rfc2989.txt- network access. In creating this documents, inputs were taken from
../data/rfc/rfc2989.txt- documents produced by the NASREQ [3], ROAMOPS [2], and MOBILEIP [5]
../data/rfc/rfc2989.txt- working groups, as well as from TIA 45.6 [4]. This document
../data/rfc/rfc2989.txt- summarizes the requirements collected from those sources, separating
../data/rfc/rfc2989.txt: requirements for authentication, authorization and accounting.
../data/rfc/rfc2989.txt- Details on the requirements are available in the original documents.
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt-1.1. Requirements language
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt- In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
--
../data/rfc/rfc2989.txt-RFC 2989 Network Access AAA Evaluation Criteria November 2000
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt-1.2. Terminology
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt: Accounting
../data/rfc/rfc2989.txt- The act of collecting information on resource usage for the
../data/rfc/rfc2989.txt- purpose of trend analysis, auditing, billing, or cost
../data/rfc/rfc2989.txt- allocation.
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt- Administrative Domain
--
../data/rfc/rfc2989.txt- Hop-by-hop is the security model that requires that each
../data/rfc/rfc2989.txt- direct set of peers in a proxy network share a security
../data/rfc/rfc2989.txt- association, and the security information does not traverse
../data/rfc/rfc2989.txt- a AAA entity.
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt: Inter-domain Accounting
../data/rfc/rfc2989.txt: Inter-domain accounting is the collection of information on
../data/rfc/rfc2989.txt- resource usage of an entity within an administrative
../data/rfc/rfc2989.txt- domain, for use within another administrative domain. In
../data/rfc/rfc2989.txt: inter-domain accounting, accounting packets and session
../data/rfc/rfc2989.txt- records will typically cross administrative boundaries.
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt: Intra-domain Accounting
../data/rfc/rfc2989.txt: Intra-domain accounting is the collection of information on
../data/rfc/rfc2989.txt- resource within an administrative domain, for use within
../data/rfc/rfc2989.txt: that domain. In intra-domain accounting, accounting
../data/rfc/rfc2989.txt- packets and session records typically do not cross
../data/rfc/rfc2989.txt- administrative boundaries.
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt- Local Domain
../data/rfc/rfc2989.txt- An administrative domain containing the AAA infrastructure
--
../data/rfc/rfc2989.txt- A Proxy Broker is a AAA entity that satisfies the
../data/rfc/rfc2989.txt- definition of a Broker, and acts as a Transparent Proxy by
../data/rfc/rfc2989.txt- acting as the forwarding agent for all AAA messages between
../data/rfc/rfc2989.txt- the local ISP and the home domain's AAA servers.
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt: Real-time Accounting
../data/rfc/rfc2989.txt: Real-time accounting involves the processing of information
../data/rfc/rfc2989.txt- on resource usage within a defined time window. Time
../data/rfc/rfc2989.txt- constraints are typically imposed in order to limit
../data/rfc/rfc2989.txt- financial risk.
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt-
--
../data/rfc/rfc2989.txt- might be required include ISP "confederations" and ISP-
../data/rfc/rfc2989.txt- provided corporate network access support.
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt- Session record
../data/rfc/rfc2989.txt- A session record represents a summary of the resource
../data/rfc/rfc2989.txt: consumption of a user over the entire session. Accounting
../data/rfc/rfc2989.txt- gateways creating the session record may do so by
../data/rfc/rfc2989.txt: processing interim accounting events.
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt- Transparent Proxy
../data/rfc/rfc2989.txt- A Transparent Proxy is a AAA server that satisfies the
../data/rfc/rfc2989.txt- definition of a Proxy, but does not enforce any local
../data/rfc/rfc2989.txt- policies (meaning that it does not add, delete or modify
--
../data/rfc/rfc2989.txt- login control, port usage limitations, or IP address pooling.
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt- The design must provide for recovery from data loss due to a
../data/rfc/rfc2989.txt- variety of faults, including NAS and AAA server reboots, and
../data/rfc/rfc2989.txt- NAS/AAA server communication outages, and MUST be independent of
../data/rfc/rfc2989.txt: the accounting stream. The granularity of the recovery of state
../data/rfc/rfc2989.txt- information after an outage may be on the order of a fraction of
../data/rfc/rfc2989.txt- a minute. In order to provide for state recovery, explicit
../data/rfc/rfc2989.txt- session/resource status and update and disconnect messages will
../data/rfc/rfc2989.txt- be required.
../data/rfc/rfc2989.txt-
--
../data/rfc/rfc2989.txt-Aboba, et al. Informational [Page 15]
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt-RFC 2989 Network Access AAA Evaluation Criteria November 2000
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt:2.4. Accounting Requirements
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
../data/rfc/rfc2989.txt- | | | | |
../data/rfc/rfc2989.txt: | Accounting | NASREQ | ROAMOPS | MOBILE |
../data/rfc/rfc2989.txt- | Reqts. | | | IP |
../data/rfc/rfc2989.txt- | | | | |
../data/rfc/rfc2989.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
../data/rfc/rfc2989.txt- | | | | |
../data/rfc/rfc2989.txt: | Real-time accounting | M | M | M |
../data/rfc/rfc2989.txt- | a | 14 | 7 | 31 |
../data/rfc/rfc2989.txt- | | | | |
../data/rfc/rfc2989.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
../data/rfc/rfc2989.txt- | | | | |
../data/rfc/rfc2989.txt- | Mandatory Compact | | M | |
../data/rfc/rfc2989.txt- | Encoding | | 7 | |
../data/rfc/rfc2989.txt- | b | | | |
../data/rfc/rfc2989.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
../data/rfc/rfc2989.txt- | | | | |
../data/rfc/rfc2989.txt: | Accounting Record | | M | M |
../data/rfc/rfc2989.txt- | Extensibility | | 7 | 33 |
../data/rfc/rfc2989.txt- | | | | |
../data/rfc/rfc2989.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
../data/rfc/rfc2989.txt- | | | | |
../data/rfc/rfc2989.txt: | Batch Accounting | S | | |
../data/rfc/rfc2989.txt- | c | 21 | | |
../data/rfc/rfc2989.txt- | | | | |
../data/rfc/rfc2989.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
../data/rfc/rfc2989.txt- | | | | |
../data/rfc/rfc2989.txt- | Guaranteed Delivery | M | | M |
../data/rfc/rfc2989.txt- | d | 22 | | 31 |
../data/rfc/rfc2989.txt- | | | | |
../data/rfc/rfc2989.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
../data/rfc/rfc2989.txt- | | | | |
../data/rfc/rfc2989.txt: | Accounting Time Stamps | M | | M |
../data/rfc/rfc2989.txt- | e | 23 | | 40 |
../data/rfc/rfc2989.txt- | | | | |
../data/rfc/rfc2989.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
../data/rfc/rfc2989.txt- | | | | |
../data/rfc/rfc2989.txt: | Dynamic Accounting | M | | |
../data/rfc/rfc2989.txt- | f | 48 | | |
../data/rfc/rfc2989.txt- | | | | |
../data/rfc/rfc2989.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt-
--
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt- [a] This requirement may be loosely defined as reporting
../data/rfc/rfc2989.txt- synchronously with events. Typically the time window is on the
../data/rfc/rfc2989.txt- order of seconds, not milliseconds.
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt: [b] The AAA protocol's Accounting data format MUST NOT be bloated,
../data/rfc/rfc2989.txt: imposing a large overhead for one or more accounting data
../data/rfc/rfc2989.txt- elements.
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt- [c] This requirement refers to the ability to buffer or store
../data/rfc/rfc2989.txt: multiple accounting records, and send them together at some
../data/rfc/rfc2989.txt- later time.
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt- [d] This is an application layer acknowledgment. This is sent when
../data/rfc/rfc2989.txt- the receiving server is willing to take responsibility for the
../data/rfc/rfc2989.txt- message data.
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt- [e] This requirement refers to the ability to reflect the time of
../data/rfc/rfc2989.txt- occurrence of events such as log-on, logoff, authentication,
../data/rfc/rfc2989.txt: authorization and interim accounting. It also implies the
../data/rfc/rfc2989.txt- ability to provide for unambiguous time-stamps.
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt- [f] This requirement refers to the ability to account for dynamic
../data/rfc/rfc2989.txt- authentication and authorization. To support this, there can be
../data/rfc/rfc2989.txt: multiple accounting records for a single session.
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt-2.5. Unique Mobile IP requirements
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt- In addition to the above requirements, Mobile IP also has the
../data/rfc/rfc2989.txt- following additional requirements:
--
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt-RFC 2989 Network Access AAA Evaluation Criteria November 2000
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt- [5] Glass, S., Hiller, T., Jacobs, S. and C. Perkins, "Mobile IP
../data/rfc/rfc2989.txt: Authentication, Authorization, and Accounting Requirements", RFC
../data/rfc/rfc2989.txt- 2977, October 2000.
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt- [6] Mitton, D., Beadles, M., "Network Access Server Requirements
../data/rfc/rfc2989.txt- Next Generation (NASREQNG) NAS Model", RFC 2881, July 2000.
../data/rfc/rfc2989.txt-
--
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt- [9] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
../data/rfc/rfc2989.txt- Authentication Dial In User Service (RADIUS)", RFC 2865, June
../data/rfc/rfc2989.txt- 2000.
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt: [10] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt- [11] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
../data/rfc/rfc2989.txt- 51, RFC 1661, July 1994.
../data/rfc/rfc2989.txt-
../data/rfc/rfc2989.txt- [12] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti,
--
../data/rfc/rfc6738.txt- that these rules are agreed to by the external protocol on a peer
../data/rfc/rfc6738.txt- side providing the key to the IKEv2 peer, and on the Diameter server
../data/rfc/rfc6738.txt- side providing the key to the IKEv2 server. This document allows for
../data/rfc/rfc6738.txt- the SK to be obtained for a specific IKEv2 session and exchanged
../data/rfc/rfc6738.txt- between IKEv2 server and the Home Authentication, Authorization, and
../data/rfc/rfc6738.txt: Accounting (HAAA) server. The protocol provides IKEv2 attributes to
../data/rfc/rfc6738.txt- allow the HAAA to compute the SK specific to the session if desired
../data/rfc/rfc6738.txt- (see Section 10). This is accomplished through the use of a new
../data/rfc/rfc6738.txt- Diameter application specifically designed for performing IKEv2
../data/rfc/rfc6738.txt- authorization decisions. This document focuses on the IKEv2 server,
../data/rfc/rfc6738.txt- as a Diameter client, communicating to the Diameter server, and it
--
../data/rfc/rfc6738.txt-
../data/rfc/rfc6738.txt- EAP Extensible Authentication Protocol
../data/rfc/rfc6738.txt-
../data/rfc/rfc6738.txt- ESP Encapsulating Security Payload
../data/rfc/rfc6738.txt-
../data/rfc/rfc6738.txt: HAAA Home Authentication, Authorization, and Accounting
../data/rfc/rfc6738.txt-
../data/rfc/rfc6738.txt- IKEv2 Internet Key Exchange Protocol version 2
../data/rfc/rfc6738.txt-
../data/rfc/rfc6738.txt- NAI Network Access Identifier
../data/rfc/rfc6738.txt-
--
../data/rfc/rfc7786.txt- Section 4 details how to set the CDO marking based on this congestion
../data/rfc/rfc7786.txt- information. Section 5 discusses the loss of packets carrying ConEx
../data/rfc/rfc7786.txt- information. Section 6 discusses the timeliness of the ConEx
../data/rfc/rfc7786.txt- feedback signal, given that congestion is a temporary state.
../data/rfc/rfc7786.txt-
../data/rfc/rfc7786.txt: This document describes congestion accounting for TCP with and
../data/rfc/rfc7786.txt- without the Selective Acknowledgement (SACK) extension [RFC2018] (in
../data/rfc/rfc7786.txt- Section 3.1). However, ConEx benefits from the more accurate
../data/rfc/rfc7786.txt- information that SACK provides about the number of bytes dropped in
../data/rfc/rfc7786.txt- the network, and it is therefore preferable to use the SACK extension
../data/rfc/rfc7786.txt- when using TCP with ConEx. The detailed mechanism to set the L flag
--
../data/rfc/rfc7786.txt-
../data/rfc/rfc7786.txt-
../data/rfc/rfc7786.txt- feedback extension to ECN (AccECN) is proposed in a separate document
../data/rfc/rfc7786.txt- [ACCURATE], as this is also useful for other mechanisms.
../data/rfc/rfc7786.txt-
../data/rfc/rfc7786.txt: Congestion accounting for both classic ECN feedback and AccECN
../data/rfc/rfc7786.txt- feedback is explained in detail in Section 3.2. Setting the E flag
../data/rfc/rfc7786.txt- in response to ECN-based congestion feedback is again detailed in
../data/rfc/rfc7786.txt- Section 4.1.
../data/rfc/rfc7786.txt-
../data/rfc/rfc7786.txt-1.1. Requirements Language
--
../data/rfc/rfc2924.txt-Category: Informational A. Blount
../data/rfc/rfc2924.txt- MetraTech Corp.
../data/rfc/rfc2924.txt- September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: Accounting Attributes and Record Formats
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Status of this Memo
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- This memo provides information for the Internet community. It does
../data/rfc/rfc2924.txt- not specify an Internet standard of any kind. Distribution of this
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Abstract
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- This document summarises Internet Engineering Task Force (IETF) and
../data/rfc/rfc2924.txt- International Telecommunication Union (ITU-T) documents related to
../data/rfc/rfc2924.txt: Accounting. A classification scheme for the Accounting Attributes in
../data/rfc/rfc2924.txt- the summarised documents is presented. Exchange formats for
../data/rfc/rfc2924.txt: Accounting data records are discussed, as are advantages and
../data/rfc/rfc2924.txt- disadvantages of integrated versus separate record formats and
../data/rfc/rfc2924.txt- transport protocols. This document discusses service definition
../data/rfc/rfc2924.txt- independence, extensibility, and versioning. Compound service
../data/rfc/rfc2924.txt- definition capabilities are described.
../data/rfc/rfc2924.txt-
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 1]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- 4.7. QoS: RSVP and DIFFSERV . . . . . . . . . . . . . . . . . . . 12
../data/rfc/rfc2924.txt- 4.7.1. QoS: RSVP and DIFFSERV Attributes . . . . . . . . . . . . 13
../data/rfc/rfc2924.txt- 5. ITU-T Documents . . . . . . . . . . . . . . . . . . . . . . . 13
../data/rfc/rfc2924.txt- 5.1. Q.825: Call Detail Recording . . . . . . . . . . . . . . . . 13
../data/rfc/rfc2924.txt- 5.2. Q.825 Attributes . . . . . . . . . . . . . . . . . . . . . . 14
../data/rfc/rfc2924.txt- 6. Other Documents . . . . . . . . . . . . . . . . . . . . . . . 18
../data/rfc/rfc2924.txt- 6.1. TIPHON: ETSI TS 101 321 . . . . . . . . . . . . . . . . . . 18
../data/rfc/rfc2924.txt- 6.2. MSIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
../data/rfc/rfc2924.txt: 7. Accounting File and Record Formats . . . . . . . . . . . . . . 19
../data/rfc/rfc2924.txt- 7.1. ASN.1 Records . . . . . . . . . . . . . . . . . . . . . . . 19
../data/rfc/rfc2924.txt- 7.1.1. RTFM and AToMMIB . . . . . . . . . . . . . . . . . . . . . 19
../data/rfc/rfc2924.txt- 7.1.2. Q.825 . . . . . . . . . . . . . . . . . . . . . . . . . . 20
../data/rfc/rfc2924.txt- 7.2. Binary Records . . . . . . . . . . . . . . . . . . . . . . . 20
../data/rfc/rfc2924.txt- 7.2.1. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . 20
--
../data/rfc/rfc2924.txt- 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . 36
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-1. Introduction
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- This document summarises IETF and ITU-T documents related to
../data/rfc/rfc2924.txt: Accounting. For those documents which describe Accounting Attributes
../data/rfc/rfc2924.txt- (i.e. quantities which can be measured and reported), an Attribute
../data/rfc/rfc2924.txt- Summary is given. Although several of the documents describe
../data/rfc/rfc2924.txt- Attributes which are similar, no attempt is made to identify those
../data/rfc/rfc2924.txt- which are the same in several documents. An extensible
../data/rfc/rfc2924.txt: classification scheme for AAA Accounting Attributes is proposed; it
../data/rfc/rfc2924.txt- is a superset of the attributes in all the documents summarised.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 2]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: Many existing accounting record formats and protocols [RAD-ACT]
../data/rfc/rfc2924.txt- [TIPHON] are of limited use due to their single-service descriptive
../data/rfc/rfc2924.txt- facilities and lack of extensibility. While some record formats and
../data/rfc/rfc2924.txt- protocols support extensible attributes [RAD-ACT], none provide
../data/rfc/rfc2924.txt- identification, type checking, or versioning support for defined
../data/rfc/rfc2924.txt- groupings of attributes (service definitions). This document makes a
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-2. Terminology and Notation
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- The following terms are used throughout the document.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: Accounting Server
../data/rfc/rfc2924.txt- A network element that accepts Usage Events from Service Elements.
../data/rfc/rfc2924.txt- It acts as an interface to back-end rating, billing, and
../data/rfc/rfc2924.txt- operations support systems.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- Attribute-Value Pair (AVP)
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 3]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- Usage Attribute
../data/rfc/rfc2924.txt- A component of a Usage Event that describes some metric of service
../data/rfc/rfc2924.txt- usage.
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-3. Architecture Model
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- Service Elements provide Services to Service Consumers. Before,
../data/rfc/rfc2924.txt- while, and/or after services are provided, the Service Element
../data/rfc/rfc2924.txt: reports Usage Events to an Accounting Server. Alternately, the
../data/rfc/rfc2924.txt: Accounting Server may query the Service Element for Usage Events.
../data/rfc/rfc2924.txt- Usage events are sent singly or in bulk.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- +------------+ +-----------+ +------------+
../data/rfc/rfc2924.txt: | Service |<----->| Service | Usage Events | Accounting |
../data/rfc/rfc2924.txt- | Consumer | +-->| Element |------------->| Server |
../data/rfc/rfc2924.txt- +------------+ | +-----------+ +------------+
../data/rfc/rfc2924.txt- |
../data/rfc/rfc2924.txt- +------------+ |
../data/rfc/rfc2924.txt- | Service |<--+
../data/rfc/rfc2924.txt- | Consumer |
../data/rfc/rfc2924.txt- +------------+
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: Accounting Servers may forward Usage Events to other systems,
../data/rfc/rfc2924.txt- possibly in other administrative domains. These transfers are not
../data/rfc/rfc2924.txt- addressed by this document.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-4. IETF Documents
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- In March 1999 there were at least 19 Internet Drafts and 8 RFCs
../data/rfc/rfc2924.txt: concerned with Accounting. These are summarised (by working group)
../data/rfc/rfc2924.txt- in the following sections.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-4.1. RADIUS
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- The RADIUS protocol [RAD-PROT] carries authentication, authorization
--
../data/rfc/rfc2924.txt- protocol are expressed in terms of RADIUS attributes such as User-
../data/rfc/rfc2924.txt- Name, Service-Type, and so on. These attributes provide the
../data/rfc/rfc2924.txt- information needed by a RADIUS server to authenticate users and to
../data/rfc/rfc2924.txt- establish authorized network service for them.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: The protocol was extended to carry accounting information between a
../data/rfc/rfc2924.txt: NAS and a shared accounting server. This was achieved by defining a
../data/rfc/rfc2924.txt: set of RADIUS accounting attributes [RAD-ACT].
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 4]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- RADIUS packets have a short header containing the RADIUS packet type
../data/rfc/rfc2924.txt- and authenticator (sixteen octets) and length, followed by a sequence
../data/rfc/rfc2924.txt- of (Type, Length, Value) triples, one for each attribute.
--
../data/rfc/rfc2924.txt- 4 NAS-IP-Address 60 CHAP-Challenge
../data/rfc/rfc2924.txt- 5 NAS-Port 61 NAS-Port-Type
../data/rfc/rfc2924.txt- 6 Service-Type 62 Port-Limit
../data/rfc/rfc2924.txt- 7 Framed-Protocol 63 Login-LAT-Port
../data/rfc/rfc2924.txt- 8 Framed-IP-Address
../data/rfc/rfc2924.txt: 9 Framed-IP-Netmask RADIUS Accounting Attributes
../data/rfc/rfc2924.txt- 10 Framed-Routing [RAD-ACT]
../data/rfc/rfc2924.txt- 11 Filter-Id
../data/rfc/rfc2924.txt- 12 Framed-MTU 40 Acct-Status-Type
../data/rfc/rfc2924.txt- 13 Framed-Compression 41 Acct-Delay-Time
../data/rfc/rfc2924.txt- 14 Login-IP-Host 42 Acct-Input-Octets
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 5]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- 29 Termination-Action 53 Acct-Output-Gigawords
../data/rfc/rfc2924.txt- 30 Called-Station-Id 54 Unused
../data/rfc/rfc2924.txt- 31 Calling-Station-Id 55 Event-Timestamp
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 6]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- DIAMETER defines a base protocol that specifies the header formats,
../data/rfc/rfc2924.txt- security extensions and requirements as well as a small number of
../data/rfc/rfc2924.txt- mandatory commands and AVPs. A new service can extend DIAMETER by
--
../data/rfc/rfc2924.txt- One key differentiator with DIAMETER is its inherent support for
../data/rfc/rfc2924.txt- Inter-Server communication. Although this can be achieved in a
../data/rfc/rfc2924.txt- variety of ways, the most useful feature is the ability to "proxy"
../data/rfc/rfc2924.txt- messages across a set of DIAMETER servers (known as a proxy chain).
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: The DIAMETER Accounting Extension document [DIAM-ACT] extends
../data/rfc/rfc2924.txt: DIAMETER by defining a protocol for securely transferring accounting
../data/rfc/rfc2924.txt- records over the DIAMETER base protocol. This includes the case
../data/rfc/rfc2924.txt: where accounting records may be passed through one or more
../data/rfc/rfc2924.txt- intermediate proxies, in accordance with the 'referral broker' model.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: The DIAMETER accounting protocol [DIAM-ACT] defines DIAMETER records
../data/rfc/rfc2924.txt- for transferring an ADIF record (see below). It introduces five new
../data/rfc/rfc2924.txt: attributes (480..485) which specify the way in which accounting
../data/rfc/rfc2924.txt- information is to be delivered between DIAMETER servers.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-4.2.1. DIAMETER Attributes
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- DIAMETER AVPs are identified by a 16-bit number defined in [DIAM-
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 7]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: 480 Accounting-Record-Type
../data/rfc/rfc2924.txt- 481 ADIF-Record
../data/rfc/rfc2924.txt: 482 Accounting-Interim-Interval
../data/rfc/rfc2924.txt: 483 Accounting-Delivery-Max-Batch
../data/rfc/rfc2924.txt: 484 Accounting-Delivery-Max-Delay
../data/rfc/rfc2924.txt: 485 Accounting-Record-Number
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- 600 SIP-Sequence
../data/rfc/rfc2924.txt- 601 SIP-Call-ID
../data/rfc/rfc2924.txt- 602 SIP-To
../data/rfc/rfc2924.txt- 603 SIP-From
--
../data/rfc/rfc2924.txt- [ROAM-IMPL] reviews the design and functionality of existing roaming
../data/rfc/rfc2924.txt- implementations. "Roaming capability" may be loosely defined as the
../data/rfc/rfc2924.txt- ability to use any one of multiple Internet service providers (ISPs),
../data/rfc/rfc2924.txt- while maintaining a formal customer-vendor relationship with only
../data/rfc/rfc2924.txt- one. One requirement for successful roaming is the provision of
../data/rfc/rfc2924.txt: effective accounting.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: [ROAM-ADIF] proposes a standard accounting record format, the
../data/rfc/rfc2924.txt: Accounting Data Interchange Format (ADIF), which is designed to
../data/rfc/rfc2924.txt: compactly represent accounting data in a protocol-independent manner.
../data/rfc/rfc2924.txt: As a result, ADIF may be used to represent accounting data from any
../data/rfc/rfc2924.txt- protocol using attribute value pairs (AVPs) or variable bindings.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: ADIF does not define accounting attributes of its own. Instead, it
../data/rfc/rfc2924.txt: gives examples of accounting records using the RADIUS accounting
../data/rfc/rfc2924.txt- attributes.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-4.4. RTFM
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- The RTFM Architecture [RTFM-ARC] provides a general method of
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 8]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- required attribute within a BER-encoded sequence. This means there
../data/rfc/rfc2924.txt- is only one object identifier for the whole sequence, greatly
../data/rfc/rfc2924.txt- reducing the number of bytes required to retrieve the data.
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 9]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- 36 Source Class Integer "Computed" attributes
../data/rfc/rfc2924.txt- 37 Destination Class Integer
../data/rfc/rfc2924.txt- 38 Flow Class Integer
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-4.5. ISDN MIB
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- The ISDN MIB [ISDN-MIB] defines a minimal set of managed objects for
../data/rfc/rfc2924.txt- SNMP-based management of ISDN terminal interfaces. It does not
../data/rfc/rfc2924.txt: explicitly define anything related to accounting, however it does
../data/rfc/rfc2924.txt- define isdnBearerChargedUnits as
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- The number of charged units for the current or last connection.
../data/rfc/rfc2924.txt- For incoming calls or if charging information is not supplied by
../data/rfc/rfc2924.txt- the switch, the value of this object is zero.
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 10]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- isdnBearerCallConnectTime TimeStamp,
../data/rfc/rfc2924.txt- isdnBearerChargedUnits Gauge32
../data/rfc/rfc2924.txt- }
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-4.6. AToMMIB
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: The "ATM Accounting Information MIB" document [ATM-ACT] describes a
../data/rfc/rfc2924.txt: large set of accounting objects for ATM connections. An
../data/rfc/rfc2924.txt- administrator may select objects from this set using a selector of
../data/rfc/rfc2924.txt- the form (subtree, list) where "subtree" specifies an object
../data/rfc/rfc2924.txt- identifier from the AToMMIB. For each subtree there is a table
../data/rfc/rfc2924.txt- holding values for each ATM connection. The required connections are
../data/rfc/rfc2924.txt- indicated by setting bits in "list", which is an octet string. For
../data/rfc/rfc2924.txt- example, the set containing the number of received cells for the
../data/rfc/rfc2924.txt- first eight ATM connections would be selected by
../data/rfc/rfc2924.txt- (atmAcctngReceivedCells, 0xFF).
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: The Connection-Oriented Accounting MIB document [ATM-COLL] defines a
../data/rfc/rfc2924.txt- MIB providing managed objects used for controlling the collection and
../data/rfc/rfc2924.txt: storage of accounting information for connection-oriented networks
../data/rfc/rfc2924.txt: such as ATM. The accounting data is collected into files for later
../data/rfc/rfc2924.txt: retrieval via a file transfer protocol. Records within an accounting
../data/rfc/rfc2924.txt- file are stored as BER strings [ASN1, BER].
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-4.6.1. AToMMIB Attributes
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: Accounting data objects within the AToMMBIB are identified by the
../data/rfc/rfc2924.txt- last integer in their object identifiers.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: The ATM accounting data objects are:
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- 1 atmAcctngConnectionType
../data/rfc/rfc2924.txt- 2 atmAcctngCastType
../data/rfc/rfc2924.txt- 3 atmAcctngIfName
../data/rfc/rfc2924.txt- 4 atmAcctngIfAlias
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 11]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- 18 atmAcctngReceivedClp0Cells
../data/rfc/rfc2924.txt- 19 atmAcctngTransmitTrafficDescriptorType
../data/rfc/rfc2924.txt- 20 atmAcctngTransmitTrafficDescriptorParam1
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 12]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-4.7.1. RSVP and DIFFSERV Attributes
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- A set of parameters for specifying a requested Quality of Service are
../data/rfc/rfc2924.txt: given in [IIS-SPEC]. These have been turned into accounting
../data/rfc/rfc2924.txt- attributes within RTFM [RTFM-NEWA] and within the RSVP MIB [RSVP-
../data/rfc/rfc2924.txt- MIB].
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- The RTFM QoS attributes are:
../data/rfc/rfc2924.txt-
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- The Session tables contain information such as the numbers of senders
../data/rfc/rfc2924.txt- and receivers for each session, while the Reservation Requests tables
../data/rfc/rfc2924.txt- contain details of requests handled by the RSVP router. There are
../data/rfc/rfc2924.txt- too many objects to list here, but many of them could be used for
../data/rfc/rfc2924.txt: accounting. In particular, RSVP Requests contain the specification
../data/rfc/rfc2924.txt- of the service parameters requested by a user; these, together with
../data/rfc/rfc2924.txt: the actual usage data for the connection make up an accounting record
../data/rfc/rfc2924.txt- for that usage.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-5. ITU-T Documents
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-5.1. Q.825: Call Detail Recording
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 13]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- Each call produces one or more records describing events that
../data/rfc/rfc2924.txt- occurred during the life of a call. Data may be produced in real
../data/rfc/rfc2924.txt- time (single CDRs), near real-time (blocks of CDRs), or as batch
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 14]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- 9 calledPartyNumber
../data/rfc/rfc2924.txt- Telephone number of the called subscriber (may be a
../data/rfc/rfc2924.txt- "diverted-to" or "translated" number.
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 15]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- 20 dataValidity
../data/rfc/rfc2924.txt- Indicates that the NE is having problems, contents of the
../data/rfc/rfc2924.txt- generated Call Detail record is not reliable.
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 16]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- 37 networkProviderId
../data/rfc/rfc2924.txt- Indicates the Network Provider for whom the CDR is generated.
../data/rfc/rfc2924.txt-
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 17]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- 52 receivedDigits
../data/rfc/rfc2924.txt- The digits dialed by the subscriber. (Normally only included
../data/rfc/rfc2924.txt- for customer care purposes).
--
../data/rfc/rfc2924.txt-6. Other Documents
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-6.1. TIPHON: ETSI TS 101 321
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- TIPHON [TIPHON] is an XML-based protocol, carried by HTTP, which
../data/rfc/rfc2924.txt: handles accounting and authorization requests and responses.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- The following are elements selected from TIPHON's DTD that are used
../data/rfc/rfc2924.txt: for accounting.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- <!ELEMENT Currency (#PCDATA)> <!ELEMENT Amount (#PCDATA)>
../data/rfc/rfc2924.txt- Identifies a numeric value. Expressed using the period (.) as a
../data/rfc/rfc2924.txt- decimal separator with no punctuation as the thousands separator.
../data/rfc/rfc2924.txt-
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 18]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- <!ELEMENT DestinationInfo type ( e164 | h323 | url | email |
../data/rfc/rfc2924.txt- transport | international |
../data/rfc/rfc2924.txt- national | network | subscriber |
--
../data/rfc/rfc2924.txt- Collects information describing the usage of a service.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-6.2. MSIX
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- MSIX [MSIX-SPEC] is an XML-based protocol transported by HTTP that is
../data/rfc/rfc2924.txt: used to make accounting service definitions and transmit service
../data/rfc/rfc2924.txt- usage information. As its service definitions are parameterized and
../data/rfc/rfc2924.txt- dynamic, it makes no definition of services or attributes itself, but
../data/rfc/rfc2924.txt- allows implementors to make their own. It specifies only the base
../data/rfc/rfc2924.txt- data types that attributes may take: STRING, UNISTRING, INT32, FLOAT,
../data/rfc/rfc2924.txt- DOUBLE, BOOLEAN, TIMESTAMP.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:7. Accounting File and Record Formats
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-7.1. ASN.1 Records
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-7.1.1. RTFM and AToMMIB
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- RTFM and AToMMIB use ASN.1 Basic Encoding Rules (BER) to encode lists
../data/rfc/rfc2924.txt: of attributes into accounting records. RTFM uses SNMP to retrieve
../data/rfc/rfc2924.txt- such records as BER strings, thus avoiding having to have an object
../data/rfc/rfc2924.txt- identifier for every object.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 19]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: AToMMIB carries this a stage further by defining an accounting file
../data/rfc/rfc2924.txt- format in ASN.1 and making it available for retrieval by a file
../data/rfc/rfc2924.txt- transfer protocol, thereby providing a more efficient alternative to
../data/rfc/rfc2924.txt- simply retrieving the records using SNMP.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-7.1.2. Q.825
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 20]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- Code
../data/rfc/rfc2924.txt- The AVP Code identifies the attribute uniquely. If the Vendor-
../data/rfc/rfc2924.txt- Specific bit is set, the AVP Code is allocated from the
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-7.3. Text Records
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-7.3.1. ROAMOPS
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: ADIF (Accounting Data Interchange Format [ROAM-ADIF]) presents a
../data/rfc/rfc2924.txt: general, text-based format for accounting data files, described in a
../data/rfc/rfc2924.txt- straightforward BNF grammar. Its file header contains a field
../data/rfc/rfc2924.txt: indicating the default protocol from which accounting attributes are
../data/rfc/rfc2924.txt- drawn. If an attribute from another protocol is to be used, it is
../data/rfc/rfc2924.txt- preceded by its protocol name, for example rtfm//27 would be RTFM's
../data/rfc/rfc2924.txt- "forward bytes" attribute. Comments in an ADIF file begin with a
../data/rfc/rfc2924.txt- cross-hatch.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: Example: An ADIF file encoding RADIUS accounting data
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- version: 1
../data/rfc/rfc2924.txt- device: server3
../data/rfc/rfc2924.txt: description: Accounting Server 3
../data/rfc/rfc2924.txt- date: 02 Mar 1999 12:19:01 -0500
../data/rfc/rfc2924.txt- defaultProtocol: radius
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- rdate: 02 Mar 1999 12:20:17 -0500
../data/rfc/rfc2924.txt- #NAS-IP-Address
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 21]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- 61: 2
../data/rfc/rfc2924.txt- #User-Name
../data/rfc/rfc2924.txt- 1: fred@bigco.com
--
../data/rfc/rfc2924.txt-8. AAA Requirements
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-8.1. A Well-Defined Set of Attributes
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- AAA needs a well-defined set of attributes whose values are to be
../data/rfc/rfc2924.txt: carried in records to or from accounting servers.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- Most of the existing sets of documents described above include a set
../data/rfc/rfc2924.txt- of attributes, identified by small integers. It is likely that these
../data/rfc/rfc2924.txt- sets overlap, i.e. that some of them have attributes which represent
../data/rfc/rfc2924.txt- the same quantity using different names in different sets. This
../data/rfc/rfc2924.txt- suggests it might be possible to produce a single combined set of
../data/rfc/rfc2924.txt: "universal" accounting attributes, but such a "universal" set does
../data/rfc/rfc2924.txt- not seem worthwhile.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- The ADIF approach of specifying a default protocol (from which
../data/rfc/rfc2924.txt- attributes are assumed to come) and identifying any exceptions seems
../data/rfc/rfc2924.txt- much more practical. We therefore propose that AAA should use the
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 22]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- ADIF convention (or something like it) to identify attributes,
../data/rfc/rfc2924.txt- together with all the sets of attributes covered by the [ASG-NBR]
../data/rfc/rfc2924.txt- document.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-8.2. A Simple Interchange Format
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: AAA needs a simple interchange file format, to be used for accounting
../data/rfc/rfc2924.txt- data. Several schemes for packaging and transporting such data have
../data/rfc/rfc2924.txt- been described above.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- The SNMP-based ones fit well within the context of an SNMP-based
../data/rfc/rfc2924.txt- network management system. RTFM and AToMMIB provide ways to reduce
../data/rfc/rfc2924.txt- the SNMP overhead for collecting data, and AToMMIB defines a complete
../data/rfc/rfc2924.txt: file format. Both provide good ways to collect accounting data.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- As an interchange format, however, ASN.1-based schemes suffer from
../data/rfc/rfc2924.txt- being rather complex binary structures. This means that one requires
../data/rfc/rfc2924.txt- suitable tools to work with them, as compared to plain-text files
../data/rfc/rfc2924.txt- where one can use existing text-based utilities.
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-9. Issues
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- It is generally agreed that there is a need for a standard record
../data/rfc/rfc2924.txt- format and transport protocol for communication between Service
../data/rfc/rfc2924.txt: Elements and Accounting Servers.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- There is less agreement on the following issues:
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- o Separate or integral record format and transport protocol
../data/rfc/rfc2924.txt- o Standard set of base data types
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 23]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- o Service definition namespace management
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- The following sections address these issues.
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- All known Internet-centric billing protocols to date have an integral
../data/rfc/rfc2924.txt- record format. That is, the collection of Properties that describe a
../data/rfc/rfc2924.txt- Usage Event are specified as an integral part of the protocol,
../data/rfc/rfc2924.txt- typically as a part of a "submit" message that is used to transmit a
../data/rfc/rfc2924.txt: Usage Event from a Service Entity to an Accounting Server.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- It may be advantageous to define a record format that is independent
../data/rfc/rfc2924.txt- of the transport protocol. Such a record format should support both
../data/rfc/rfc2924.txt- representation of individual records and records in bulk, as Usage
../data/rfc/rfc2924.txt- Events are often aggregated and transmitted in bulk.
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 24]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- tagged, but the order of the AVPs is undefined. The message body is
../data/rfc/rfc2924.txt- not tagged (except with an additional preceding blank line), and is
../data/rfc/rfc2924.txt- found through its position in the message, which must be after all
--
../data/rfc/rfc2924.txt- change. Tagged data allows old readers to detect unexpected tags and
../data/rfc/rfc2924.txt- to detect if required data are missing. If the overhead of carrying
../data/rfc/rfc2924.txt- explicit tags can be borne, it is advantageous to use explicitly
../data/rfc/rfc2924.txt- tagged data elements where possible.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: An AVP approach has proven useful in accounting. RADIUS [RADIUS]
../data/rfc/rfc2924.txt- uses numeric data type identifiers. ETSI's TIPHON [TIPHON] uses XML
../data/rfc/rfc2924.txt- markup.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: For an AAA accounting record format, the authors suggest that each
../data/rfc/rfc2924.txt- Property be named by a textual or numeric identifier and carry a
../data/rfc/rfc2924.txt- value and a data type indicator, which governs interpretation of the
../data/rfc/rfc2924.txt- value. It may also be useful for each Property to carry a units of
../data/rfc/rfc2924.txt- measure identifier. The TIPHON specification takes this approach.
../data/rfc/rfc2924.txt- TS 101 321 also carries an Increment field, which denominates the
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 25]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- An appropriate set would likely include booleans, 32 and 64 bit
../data/rfc/rfc2924.txt- signed integers, 32 and 64 bit floats, arbitrary octets, UTF-8 and
../data/rfc/rfc2924.txt- UTF-16 strings, and ISO 8601:1988 [ISO-DATE] timestamps. Fixed-
../data/rfc/rfc2924.txt- precision numbers capable of representing currency amounts (with
../data/rfc/rfc2924.txt- precision specified on both sides of the decimal point) have proven
../data/rfc/rfc2924.txt: useful in accounting record formats, as they are immune to the
../data/rfc/rfc2924.txt- precision problems that are encountered when one attempts to
../data/rfc/rfc2924.txt- represent fixed-point amounts with floating point numbers.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- It may be worthwhile to consider the datatypes that are being
../data/rfc/rfc2924.txt- specified by the W3C's "XML Schema Part 2: Datatypes" [XML-DATA]
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- Each Usage Event requires its own unique identifier.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- It is expedient to allow Service Elements to create their own unique
../data/rfc/rfc2924.txt- identifiers. In this manner, Usage Events can be created and
../data/rfc/rfc2924.txt: archived without the involvement of an Accounting Server or other
../data/rfc/rfc2924.txt- central authority.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- A number of methods for creating unique identifiers are well known.
../data/rfc/rfc2924.txt- One popular identifier is an amalgamation of a monotonically
../data/rfc/rfc2924.txt- increasing sequence number, a large random value, a network element
--
../data/rfc/rfc2924.txt- RFC 822 [MAIL], RFC 1036 [NEWS], and RFC 2445 [ICAL-CORE] give
../data/rfc/rfc2924.txt- guidance on the creation of good unique identifiers.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-9.4. Service Definitions
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: A critical differentiator in accounting record formats and protocols
../data/rfc/rfc2924.txt- is their capability to account for arbitrary service usage. To date,
../data/rfc/rfc2924.txt: no accounting record format or protocol that can handle arbitrary
../data/rfc/rfc2924.txt- service definitions has achieved broad acceptance on the Internet.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- This section analyzes the issues in service definition and makes a
../data/rfc/rfc2924.txt- case for a record format and protocol with the capability to carry
../data/rfc/rfc2924.txt- Usage Events for rich, independently-defined services.
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 26]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-9.4.1. Service Independence
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- It is informative to survey a number of popular Internet protocols
--
../data/rfc/rfc2924.txt- specified" protocols that have little provision for extension and
../data/rfc/rfc2924.txt- "framework" protocols that are incomplete, but provide a basis for
../data/rfc/rfc2924.txt- future extension when coupled with application documents.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- Examples of fully-specified protocols are NTP [NTP], NNTP [NNTP],
../data/rfc/rfc2924.txt: RADIUS Accounting [RAD-ACT], and HTML [HTML].
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- Aside from leaving some field values "reserved for future use", all
../data/rfc/rfc2924.txt- of Network Time Protocol's fields are fixed-width and completely
../data/rfc/rfc2924.txt- defined. This is appropriate for a simple protocol that solves a
../data/rfc/rfc2924.txt- simple problem.
--
../data/rfc/rfc2924.txt- additions. The content of news is 7-bit data, with the high-order
../data/rfc/rfc2924.txt- bit cleared to 0. Nothing further about the content is defined.
../data/rfc/rfc2924.txt- There is no in-protocol facility for automating decoding of content
../data/rfc/rfc2924.txt- type.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: We pay particular attention to RADIUS Accounting [RAD-ACT]. Perhaps
../data/rfc/rfc2924.txt- the second most frequently heard complaint (after security
../data/rfc/rfc2924.txt: shortcomings) about RADIUS Accounting is its preassigned and fixed
../data/rfc/rfc2924.txt- set of "Types". These are coded as a range of octets from 40 to 51
../data/rfc/rfc2924.txt- and are as follows:
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- 40 Acct-Status-Type
../data/rfc/rfc2924.txt- 41 Acct-Delay-Time
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 27]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- protocol limits the type identifier to a single octet, limiting the
../data/rfc/rfc2924.txt- total number of types to 256.
../data/rfc/rfc2924.txt-
--
../data/rfc/rfc2924.txt- values specific for certain applications and devices. Hence, new
../data/rfc/rfc2924.txt- functionality can continuously be added to SNMP, since a standard
../data/rfc/rfc2924.txt- method has been defined to incorporate that functionality into
../data/rfc/rfc2924.txt- SNMP devices and network managers.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: Most accounting protocols are fully-specified, with either a
../data/rfc/rfc2924.txt: completely defined service or set of services (RADIUS Accounting) or
../data/rfc/rfc2924.txt- with one or more services defined and provision for "extension"
../data/rfc/rfc2924.txt- services to be added to the protocol later (TIPHON). While the
../data/rfc/rfc2924.txt- latter is preferable, it may be preferable to take a more SNMP-like
../data/rfc/rfc2924.txt: approach, where the accounting record format and protocol provide
../data/rfc/rfc2924.txt- only a framework for service definition, and leave the task of
../data/rfc/rfc2924.txt- service definition (and standardization) to separate efforts. In
../data/rfc/rfc2924.txt: this manner, the accounting protocol itself would not have to be
../data/rfc/rfc2924.txt- modified to handle new services.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 28]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-9.4.2. Versioned Service Definitions
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- Versioning is a naming and compatibility issue. Version identifiers
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- An example could be the service definition of a phone call. Version
../data/rfc/rfc2924.txt- 1 might define Properties for the start time, duration, and called
../data/rfc/rfc2924.txt- and calling party numbers. Later, version 2 is defined, which
../data/rfc/rfc2924.txt- augments the former service definition with a byte count. An
../data/rfc/rfc2924.txt: Accounting Server, aware only of Version 1, may accept Version 2
../data/rfc/rfc2924.txt- records, discarding the additional information (forward
../data/rfc/rfc2924.txt: compatibility). Alternately, if an Accounting Server is made aware
../data/rfc/rfc2924.txt- of version 2, it could optionally still accept version 1 records from
../data/rfc/rfc2924.txt: Service Elements, provided the Accounting Sever does not require the
../data/rfc/rfc2924.txt- additional information to properly account for service usage
../data/rfc/rfc2924.txt- (backward compatibility).
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-9.4.3. Relationships Among Usage Events
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: Accounting record formats and protocols to date do not sufficiently
../data/rfc/rfc2924.txt- addressed "compound" service description.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- A compound service is a service that is described as a composition of
../data/rfc/rfc2924.txt- other services. A conference call, for example, may be described as
../data/rfc/rfc2924.txt- a number of point-to-point calls to a conference bridge. It is
../data/rfc/rfc2924.txt- important to account for the individual calls, rather than just
../data/rfc/rfc2924.txt- summing up an aggregate, both for auditing purposes and to enable
../data/rfc/rfc2924.txt- differential rating. If these calls are to be reported to the
../data/rfc/rfc2924.txt: Accounting Server individually, the Usage Events require a shared
../data/rfc/rfc2924.txt: identifier that can be used by the Accounting Server and other back-
../data/rfc/rfc2924.txt- end systems to group the records together.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- In order for a Service Element to report compound events over time as
../data/rfc/rfc2924.txt: a succession of individual Usage Events, the accounting protocol
../data/rfc/rfc2924.txt- requires a facility to communicate that the compound event has
../data/rfc/rfc2924.txt- started and stopped. The "start" message can be implicit--the
../data/rfc/rfc2924.txt- transmission of the first Usage Event will suffice. An additional
../data/rfc/rfc2924.txt: semaphore is required to tell the Accounting Server that the compound
../data/rfc/rfc2924.txt- service is complete and may be further processed. This is necessary
../data/rfc/rfc2924.txt: to prevent the Accounting Server from prematurely processing compound
../data/rfc/rfc2924.txt- events that overlap the end of a billing period.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 29]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: RADIUS Accounting has some provision for this sort of accounting with
../data/rfc/rfc2924.txt- its "Acct-Multi-Session-Id" field. Unfortunately, RADIUS
../data/rfc/rfc2924.txt: Accounting's other shortcomings preclude it from being used in
../data/rfc/rfc2924.txt- general purpose service usage description.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-9.4.4. Service Namespace Management
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- "Framework" protocols, as previously mentioned, do not define
--
../data/rfc/rfc2924.txt- As previously mentioned, the XML specification provides no facility
../data/rfc/rfc2924.txt- for DTD discovery or namespace management. XML specifies only a
../data/rfc/rfc2924.txt- document format, and as such does not need to specify support for
../data/rfc/rfc2924.txt- more "protocol" oriented problems.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: For an accounting record format and protocol, an approach closer to
../data/rfc/rfc2924.txt- SNMP's is useful. SNMP uses an ISO-managed dotted-decimal namespace.
../data/rfc/rfc2924.txt- An IANA-managed registry of service types is a possibility. Another
../data/rfc/rfc2924.txt- possibility, used by MSIX [MSIX-SPEC], is for Service Element
../data/rfc/rfc2924.txt- creators to identify their services by concatenation of a new service
../data/rfc/rfc2924.txt- name with existing unique identifier, such as a domain name.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- A standard record format for service definitions would make it
../data/rfc/rfc2924.txt: possible for Service Element creators to directly supply accounting
../data/rfc/rfc2924.txt- system managers with the required definitions, via the network or
../data/rfc/rfc2924.txt- other means.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-10. Encodings
../data/rfc/rfc2924.txt-
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 30]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- implementation is paramount and the application can tolerate any
../data/rfc/rfc2924.txt- additional processing required to generate, parse, and transport the
../data/rfc/rfc2924.txt- records.
--
../data/rfc/rfc2924.txt- A alternative "compressed" encoding that makes minimal use of storage
../data/rfc/rfc2924.txt- and processing may be useful in many contexts.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- There are disadvantages to supporting multiple encodings.
../data/rfc/rfc2924.txt- Optionally-supported multiple encodings mandate the requirement for
../data/rfc/rfc2924.txt: capabilities exchange between Service Element and Accounting Server.
../data/rfc/rfc2924.txt- Also, implementations can tend to "drift apart", with one encoding
../data/rfc/rfc2924.txt- better-supported than another. Unless all encodings are mandatory,
../data/rfc/rfc2924.txt- implementors may find they are unable to interoperate because they
../data/rfc/rfc2924.txt- picked the wrong encoding.
../data/rfc/rfc2924.txt-
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- This document summarises many existing IETF and ITU documents; please
../data/rfc/rfc2924.txt- refer to the original documents for security considerations for their
../data/rfc/rfc2924.txt- particular protocols.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: It must be possible for the accounting protocol to be carried by a
../data/rfc/rfc2924.txt- secure transport. A canonical record format is useful so that
../data/rfc/rfc2924.txt- regeneration of secure record hashes is possible.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: When dealing with accounting data files, one must take care that
../data/rfc/rfc2924.txt- their integrity and privacy are preserved. This document, however,
../data/rfc/rfc2924.txt- is only concerned with the format of such files.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-12. References
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: [ACC-BKG] Mills, C., Hirsch, G. and G. Ruth, "Internet Accounting
../data/rfc/rfc2924.txt- Background", RFC 1272, November 1991.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- [ASG-NBR] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
../data/rfc/rfc2924.txt- RFC 1700, October 1994.
../data/rfc/rfc2924.txt-
--
../data/rfc/rfc2924.txt- Notation One (ASN.1), International Organization for
../data/rfc/rfc2924.txt- Standardization, International Standard 8824, December
../data/rfc/rfc2924.txt- 1987.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- [ATM-ACT] McCloghrie, K., Heinanen, J., Greene, W. and A. Prasad,
../data/rfc/rfc2924.txt: "Accounting Information for ATM Networks", RFC 2512,
../data/rfc/rfc2924.txt- February 1999.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 31]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- [ATM-COLL] McCloghrie, K., Heinanen, J., Greene, W. and A. Prasad, "
../data/rfc/rfc2924.txt- Managed Objects for Controlling the Collection and
../data/rfc/rfc2924.txt: Storage of Accounting Information for Connection-Oriented
../data/rfc/rfc2924.txt- Networks", RFC 2513, February 1999.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- [BER] Information processing systems - Open Systems
../data/rfc/rfc2924.txt- Interconnection - Specification of Basic Encoding Rules
../data/rfc/rfc2924.txt- for Abstract Notation One (ASN.1), International
../data/rfc/rfc2924.txt- Organization for Standardization, International Standard
../data/rfc/rfc2924.txt- 8825, December 1987.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- [DIAM-ACT] Arkko, J., Calhoun, P.R., Patel, P. and Zorn, G.,
../data/rfc/rfc2924.txt: "DIAMETER Accounting Extension", Work in Progress.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- [DIAM-AUTH] Calhoun, P.R. and Bulley, W., "DIAMETER User
../data/rfc/rfc2924.txt- Authentication Extensions", Work in Progress.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- [DIAM-FRAM] Calhoun, P.R., Zorn, G. and Pan, P., "DIAMETER Framework
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 32]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- [ISO-DATE] "Data elements and interchange formats -- Information
../data/rfc/rfc2924.txt- interchange -- Representation of dates and times", ISO
../data/rfc/rfc2924.txt- 8601:1988.
--
../data/rfc/rfc2924.txt- September 1985.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- [Q-825] "Specification of TMN applications at the Q3 interface:
../data/rfc/rfc2924.txt- Call detail recording", ITU-T Recommendation Q.825, 1998.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: [RAD-ACT] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- [RAD-EXT] Rigney, C., Willats, W. and Calhoun, P., "RADIUS
../data/rfc/rfc2924.txt- Extensions", RFC 2869, June 2000.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- [RAD-PROT] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
../data/rfc/rfc2924.txt- "Remote Authentication Dial In User Service (RADIUS)",
../data/rfc/rfc2924.txt- RFC 2865, June 2000.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: [RAD-TACC] Zorn, G., Mitton, D. and A. Aboba, "RADIUS Accounting
../data/rfc/rfc2924.txt- Modifications for Tunnel Protocol Support", RFC 2867,
../data/rfc/rfc2924.txt- June 2000.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- [RAP-COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R.
../data/rfc/rfc2924.txt- and A. Sastry, "The COPS (Common Open Policy Service)
../data/rfc/rfc2924.txt- Protocol", RFC 2748, January 2000.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt: [ROAM-ADIF] Aboba, B. and D. Lidyard, "The Accounting Data
../data/rfc/rfc2924.txt- Interchange Format (ADIF)", Work in Progress.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- [ROAM-IMPL] Aboba, B., Lu, J., Alsop, J., Ding, J. and W. Wang,
../data/rfc/rfc2924.txt- "Review of Roaming Implementations", RFC 2194, September
../data/rfc/rfc2924.txt- 1997.
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 33]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- [RS-DS-OP] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L.,
../data/rfc/rfc2924.txt- Speer, M., Braden, R., Davie, B., Wroclawski, J. and E.
../data/rfc/rfc2924.txt- Felstaine, "A Framework For Integrated Services Operation
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 34]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- [XML-DATA] "XML Schema Part 2: Datatypes", W3C Working Draft 07
../data/rfc/rfc2924.txt- April 2000, April 2000.
../data/rfc/rfc2924.txt-
--
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-Brownlee & Blount Informational [Page 35]
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt:RFC 2924 Accounting Attributes and Record Formats September 2000
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt-14. Full Copyright Statement
../data/rfc/rfc2924.txt-
../data/rfc/rfc2924.txt- Copyright (C) The Internet Society (2000). All Rights Reserved.
--
../data/rfc/rfc2899.txt-
../data/rfc/rfc2899.txt-
../data/rfc/rfc2899.txt-2869 Rigney Jun 2000 RADIUS Extensions
../data/rfc/rfc2899.txt-
../data/rfc/rfc2899.txt-This document describes additional attributes for carrying
../data/rfc/rfc2899.txt:authentication, authorization and accounting information between a
../data/rfc/rfc2899.txt:Network Access Server (NAS) and a shared Accounting Server using the
../data/rfc/rfc2899.txt-Remote Authentication Dial In User Service (RADIUS) protocol described
../data/rfc/rfc2899.txt-in RFC 2865 and RFC 2866. This memo provides information for the
../data/rfc/rfc2899.txt-Internet community.
../data/rfc/rfc2899.txt-
../data/rfc/rfc2899.txt-
--
../data/rfc/rfc2899.txt-User Service) attributes designed to support the provision of compulsory
../data/rfc/rfc2899.txt-tunneling in dial-up networks. This memo provides information for the
../data/rfc/rfc2899.txt-Internet community.
../data/rfc/rfc2899.txt-
../data/rfc/rfc2899.txt-
../data/rfc/rfc2899.txt:2867 Zorn Jun 2000 RADIUS Accounting
../data/rfc/rfc2899.txt- Modifications for Tunnel
../data/rfc/rfc2899.txt- Protocol Support
../data/rfc/rfc2899.txt-
../data/rfc/rfc2899.txt-This document defines new RADIUS (Remote Authentication Dial In User
../data/rfc/rfc2899.txt:Service) accounting Attributes and new values for the existing Acct-
../data/rfc/rfc2899.txt-Status-Type Attribute designed to support the provision of compulsory
../data/rfc/rfc2899.txt-tunneling in dial-up networks. This memo provides information for the
../data/rfc/rfc2899.txt-Internet community.
../data/rfc/rfc2899.txt-
../data/rfc/rfc2899.txt-
../data/rfc/rfc2899.txt:2866 Rigney Jun 2000 RADIUS Accounting
../data/rfc/rfc2899.txt-
../data/rfc/rfc2899.txt:This document describes a protocol for carrying accounting information
../data/rfc/rfc2899.txt:between a Network Access Server and a shared Accounting Server. This
../data/rfc/rfc2899.txt-memo provides information for the Internet community.
../data/rfc/rfc2899.txt-
../data/rfc/rfc2899.txt-
../data/rfc/rfc2899.txt-
../data/rfc/rfc2899.txt-
--
../data/rfc/rfc2116.txt- such as data integrity, process persistence, and server classes. NSDS
../data/rfc/rfc2116.txt- supports access over X.25 WAN, LAN and TCP/IP networks.
../data/rfc/rfc2116.txt-
../data/rfc/rfc2116.txt- NSDS is a port of OSF's DCE GDS Reference Implementation, with Tandem
../data/rfc/rfc2116.txt- enhancements including 1993 X.500 Simplified Access Control. Tandem
../data/rfc/rfc2116.txt: server class management provides fault events, tracing, accounting and
../data/rfc/rfc2116.txt- configuration services for NSDS. TM/MP (Transaction Management) is
../data/rfc/rfc2116.txt- used to protect all file operations that affect the integrity of the
../data/rfc/rfc2116.txt- directory entries in the DIB.
../data/rfc/rfc2116.txt-
../data/rfc/rfc2116.txt- Major Features Include:
--
../data/rfc/rfc869.txt-
../data/rfc/rfc869.txt-the monitoring center that a particular event has happened by
../data/rfc/rfc869.txt-
../data/rfc/rfc869.txt-sending a trap message, while the monitoring center is reliably
../data/rfc/rfc869.txt-
../data/rfc/rfc869.txt:collecting the host's throughput and accounting data.
../data/rfc/rfc869.txt-
../data/rfc/rfc869.txt-
../data/rfc/rfc869.txt- Traps report spontaneous events, as they occur, to the
../data/rfc/rfc869.txt-
../data/rfc/rfc869.txt-monitoring center. In order to insure their prompt delivery, the
--
../data/rfc/rfc869.txt- 2 | Status
../data/rfc/rfc869.txt- 3 | Thruput
../data/rfc/rfc869.txt- 4 | HTM - Host Traffic Matrix
../data/rfc/rfc869.txt- 5 | Parameters
../data/rfc/rfc869.txt- 6 | Routing
../data/rfc/rfc869.txt: 7 | Call Accounting
../data/rfc/rfc869.txt- |
../data/rfc/rfc869.txt- 100 | Poll
../data/rfc/rfc869.txt- 101 | Error
../data/rfc/rfc869.txt- 102 | Control Acknowledgment
../data/rfc/rfc869.txt-
--
../data/rfc/rfc4285.txt- - Networks in which the authentication of the MN for network access
../data/rfc/rfc4285.txt- is done by an authentication server in the home network via the home
../data/rfc/rfc4285.txt- agent. The security association is established by the network
../data/rfc/rfc4285.txt- operator (provisioning methods) between the MN and a backend
../data/rfc/rfc4285.txt- authentication server (e.g., Authentication, Authorization, and
../data/rfc/rfc4285.txt: Accounting (AAA) home server). MIPv6 as per RFCs 3775 and 3776
../data/rfc/rfc4285.txt- relies on the IPsec SA between the MN and an HA. In cases where the
../data/rfc/rfc4285.txt- assignment of the HA is dynamic and the only static or long-term SA
../data/rfc/rfc4285.txt- is between the MN and a backend authentication server, the mobility
../data/rfc/rfc4285.txt- message authentication option is desirable.
../data/rfc/rfc4285.txt-
--
../data/rfc/rfc4285.txt-
../data/rfc/rfc4285.txt-2. Overview
../data/rfc/rfc4285.txt-
../data/rfc/rfc4285.txt- This document presents a lightweight mechanism to authenticate the
../data/rfc/rfc4285.txt- Mobile Node at the Home Agent or at the Authentication,
../data/rfc/rfc4285.txt: Authorization, and Accounting (AAA) server in Home network (AAAH)
../data/rfc/rfc4285.txt- based on a shared-key-based mobility security association between the
../data/rfc/rfc4285.txt- Mobile Node and the respective authenticating entity. This shared-
../data/rfc/rfc4285.txt- key-based mobility security association (shared-key-based mobility
../data/rfc/rfc4285.txt- SA) may be statically provisioned or dynamically created. The term
../data/rfc/rfc4285.txt-
--
../data/rfc/rfc7530.txt- With delegations, a client is able to avoid writing data to the
../data/rfc/rfc7530.txt- server when the CLOSE of a file is serviced. The file close system
../data/rfc/rfc7530.txt- call is the usual point at which the client is notified of a lack of
../data/rfc/rfc7530.txt- stable storage for the modified file data generated by the
../data/rfc/rfc7530.txt- application. At the close, file data is written to the server, and
../data/rfc/rfc7530.txt: through normal accounting the server is able to determine if the
../data/rfc/rfc7530.txt- available file system space for the data has been exceeded (i.e., the
../data/rfc/rfc7530.txt: server returns NFS4ERR_NOSPC or NFS4ERR_DQUOT). This accounting
../data/rfc/rfc7530.txt- includes quotas. The introduction of delegations requires that an
../data/rfc/rfc7530.txt- alternative method be in place for the same type of communication to
../data/rfc/rfc7530.txt- occur between client and server.
../data/rfc/rfc7530.txt-
../data/rfc/rfc7530.txt- In the delegation response, the server provides either the limit of
--
../data/rfc/rfc7530.txt-
../data/rfc/rfc7530.txt- o Different named attribute directories, or between a named
../data/rfc/rfc7530.txt- attribute directory and an ordinary directory.
../data/rfc/rfc7530.txt-
../data/rfc/rfc7530.txt- o Regions of a file system that the file system implementation
../data/rfc/rfc7530.txt: treats as separate (for example, for space accounting purposes),
../data/rfc/rfc7530.txt- and where cross-connection between the regions is not allowed.
../data/rfc/rfc7530.txt-
../data/rfc/rfc7530.txt-
../data/rfc/rfc7530.txt-
../data/rfc/rfc7530.txt-
--
../data/rfc/rfc2882.txt- 6.1 Managed Resources . . . . . . . . . . . . . . . . . . . . . 9
../data/rfc/rfc2882.txt- 6.2 Resource Management Messages . . . . . . . . . . . . . . . 10
../data/rfc/rfc2882.txt- 6.3 Concurrent Logins . . . . . . . . . . . . . . . . . . . . . 10
../data/rfc/rfc2882.txt- 6.4 Authorization Changes . . . . . . . . . . . . . . . . . . . 11
../data/rfc/rfc2882.txt- 7. Policy Services . . . . . . . . . . . . . . . . . . . . . . 11
../data/rfc/rfc2882.txt: 8. Accounting Extensions . . . . . . . . . . . . . . . . . . . 12
../data/rfc/rfc2882.txt- 8.1 Auditing/Activity . . . . . . . . . . . . . . . . . . . . . 12
../data/rfc/rfc2882.txt- 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 12
../data/rfc/rfc2882.txt- 10. Security Considerations . . . . . . . . . . . . . . . . . . 13
../data/rfc/rfc2882.txt- 11. Implementation Documents . . . . . . . . . . . . . . . . . 13
../data/rfc/rfc2882.txt- 11.1. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 13
--
../data/rfc/rfc2882.txt- VALUE Acct-Status-Type VSE-User-Reject 0x06300001
../data/rfc/rfc2882.txt- VALUE Acct-Status-Type VSE-Call-Reject 0x06300002
../data/rfc/rfc2882.txt- VALUE Acct-Status-Type VSE-IPCP-Start 0x06300003
../data/rfc/rfc2882.txt- VALUE Acct-Status-Type VSE-IPXCP-Start 0x06300004
../data/rfc/rfc2882.txt- VALUE Acct-Status-Type VSE-ATCP-Start 0x06300005
../data/rfc/rfc2882.txt: VALUE Acct-Status-Type VSE-Accounting-Restart 0x06300006
../data/rfc/rfc2882.txt: VALUE Acct-Status-Type VSE-Accounting-Shutoff 0x06300007
../data/rfc/rfc2882.txt-
../data/rfc/rfc2882.txt-
../data/rfc/rfc2882.txt-
../data/rfc/rfc2882.txt-Mitton Informational [Page 4]
../data/rfc/rfc2882.txt-
--
../data/rfc/rfc2882.txt- These fall into a number of categories which are described in the
../data/rfc/rfc2882.txt- next section below. Some of these messages are actually used between
../data/rfc/rfc2882.txt- the RADIUS server and some other resource server, using a RADIUS-like
../data/rfc/rfc2882.txt- protocol to implement new functions.
../data/rfc/rfc2882.txt-
../data/rfc/rfc2882.txt: 6 Accounting Status
../data/rfc/rfc2882.txt: (now Interim Accounting [5])
../data/rfc/rfc2882.txt- 7 Password Request
../data/rfc/rfc2882.txt- 8 Password Ack
../data/rfc/rfc2882.txt- 9 Password Reject
../data/rfc/rfc2882.txt: 10 Accounting Message
../data/rfc/rfc2882.txt-
../data/rfc/rfc2882.txt- 21 Resource Free Request
../data/rfc/rfc2882.txt- 22 Resource Free Response
../data/rfc/rfc2882.txt- 23 Resource Query Request
../data/rfc/rfc2882.txt- 24 Resource Query Response
--
../data/rfc/rfc2882.txt- There are several different types of implementation techniques:
../data/rfc/rfc2882.txt-
../data/rfc/rfc2882.txt- - Explicit request/free resource requests
../data/rfc/rfc2882.txt- - Monitor usage with deamons watching the state
../data/rfc/rfc2882.txt- - Explicit messages to a state deamon
../data/rfc/rfc2882.txt: - Monitor Accounting messages for state changes
../data/rfc/rfc2882.txt-
../data/rfc/rfc2882.txt-6.2. Resource Management Messages
../data/rfc/rfc2882.txt-
../data/rfc/rfc2882.txt- Messages used for resource management
../data/rfc/rfc2882.txt-
--
../data/rfc/rfc2882.txt- on a RADIUS environment. Some vendors have build NAS monitoring
../data/rfc/rfc2882.txt- tools either into their RADIUS servers, either directly or as
../data/rfc/rfc2882.txt- auxiliary deamons, that can check the session status of the
../data/rfc/rfc2882.txt- controlled NASes by SNMP or proprietary methods.
../data/rfc/rfc2882.txt-
../data/rfc/rfc2882.txt: Other vendors monitor the RADIUS accesses and accounting messages and
../data/rfc/rfc2882.txt- derive state information from the requests. This monitoring is not
../data/rfc/rfc2882.txt- as reliable as directly auditing the NAS, but it is also less vendor
../data/rfc/rfc2882.txt- specific, and can work with any RADIUS NAS, provided it sends both
../data/rfc/rfc2882.txt- streams to the same server.
../data/rfc/rfc2882.txt-
--
../data/rfc/rfc2882.txt-RFC 2882 Extended RADIUS Practices July 2000
../data/rfc/rfc2882.txt-
../data/rfc/rfc2882.txt-
../data/rfc/rfc2882.txt- - SNMP commands
../data/rfc/rfc2882.txt- - Telnet monitor deamon
../data/rfc/rfc2882.txt: - Accounting monitor
../data/rfc/rfc2882.txt-
../data/rfc/rfc2882.txt-6.4. Authorization Changes:
../data/rfc/rfc2882.txt-
../data/rfc/rfc2882.txt- To implement an active changes to a running session, such as filter
../data/rfc/rfc2882.txt- changes or timeout and disconnect, at least one vendor has added a
--
../data/rfc/rfc2882.txt-
../data/rfc/rfc2882.txt- The other implementation performs a similar operations. It uses VSAs
../data/rfc/rfc2882.txt- in the Access-Request to distinguish pre-authentication message
../data/rfc/rfc2882.txt- types.
../data/rfc/rfc2882.txt-
../data/rfc/rfc2882.txt:8. Accounting Extensions
../data/rfc/rfc2882.txt-
../data/rfc/rfc2882.txt: Traditional Accounting only records session starts and stops which is
../data/rfc/rfc2882.txt- pretty boring. Additional session information reporting can be added
../data/rfc/rfc2882.txt- easily which gives a better picture of operation in use as they
../data/rfc/rfc2882.txt- happen. Some event types are listed below.
../data/rfc/rfc2882.txt-
../data/rfc/rfc2882.txt-8.1. Auditing/Activity
--
../data/rfc/rfc2882.txt- find problem areas or users.
../data/rfc/rfc2882.txt-
../data/rfc/rfc2882.txt- Information about call failures, successes, and quality are also
../data/rfc/rfc2882.txt- deemed important many service providers.
../data/rfc/rfc2882.txt-
../data/rfc/rfc2882.txt: Extending RADIUS accounting is easy, it's surprising that more
../data/rfc/rfc2882.txt- implementations have not been made in this area.
../data/rfc/rfc2882.txt-
../data/rfc/rfc2882.txt-9. Conclusions
../data/rfc/rfc2882.txt-
../data/rfc/rfc2882.txt- In real life RADIUS Servers are becoming rather complex software
--
../data/rfc/rfc2882.txt-
../data/rfc/rfc2882.txt- [1] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
../data/rfc/rfc2882.txt- Authentication Dial In User Service (RADIUS)", RFC 2138, April
../data/rfc/rfc2882.txt- 1997.
../data/rfc/rfc2882.txt-
../data/rfc/rfc2882.txt: [2] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
../data/rfc/rfc2882.txt-
../data/rfc/rfc2882.txt- [3] Rigney, C., Willens, S., Ruebens, A. and W. Simpson, "Remote
../data/rfc/rfc2882.txt- Authentication Dial In User Service (RADIUS)", RFC 2865, June
../data/rfc/rfc2882.txt- 2000.
../data/rfc/rfc2882.txt-
../data/rfc/rfc2882.txt: [4] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc2882.txt-
../data/rfc/rfc2882.txt- [5] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC
../data/rfc/rfc2882.txt- 2869, June 2000.
../data/rfc/rfc2882.txt-
../data/rfc/rfc2882.txt- [6] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and
../data/rfc/rfc2882.txt- I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC
../data/rfc/rfc2882.txt- 2868, June 2000.
../data/rfc/rfc2882.txt-
../data/rfc/rfc2882.txt: [7] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
../data/rfc/rfc2882.txt- Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
../data/rfc/rfc2882.txt-
../data/rfc/rfc2882.txt- [8] Aboba, B. and G. Zorn, "Implementation of L2TP Compulsory
../data/rfc/rfc2882.txt- Tunneling via RADIUS", RFC 2809, April 2000.
../data/rfc/rfc2882.txt-
--
../data/rfc/rfc1190.txt- When the DISCONNECT reaches a target, the target sends an ACK
../data/rfc/rfc1190.txt- and notifies the application that it is no longer part of the
../data/rfc/rfc1190.txt- stream and the reason. The application should then inform ST
../data/rfc/rfc1190.txt- to terminate the stream, and ST should delete the stream from
../data/rfc/rfc1190.txt- its database after performing any necessary management and
../data/rfc/rfc1190.txt: accounting functions.
../data/rfc/rfc1190.txt-
../data/rfc/rfc1190.txt-
../data/rfc/rfc1190.txt- 3.3.3. A Target Deleting Itself
../data/rfc/rfc1190.txt-
../data/rfc/rfc1190.txt- The application at the target may inform ST that it wants to be
--
../data/rfc/rfc1190.txt- Unique ID value not be reused for a period of time on the
../data/rfc/rfc1190.txt- order of 5 minutes.
../data/rfc/rfc1190.txt-
../data/rfc/rfc1190.txt- The Timestamp is included both to make the Name unique over
../data/rfc/rfc1190.txt- long intervals (e.g., forever) for purposes of network
../data/rfc/rfc1190.txt: management and accounting/billing, and to protect against
../data/rfc/rfc1190.txt- failure of an ST agent that causes knowledge of active
../data/rfc/rfc1190.txt- Unique IDs to be lost. The assumption is that all ST agents
../data/rfc/rfc1190.txt- have access to some "clock". If this is not the case, the
../data/rfc/rfc1190.txt- agent should have access to some form of non-volatile memory
../data/rfc/rfc1190.txt- in which it can store some number that at least gets
--
../data/rfc/rfc2867.txt- D. Mitton
../data/rfc/rfc2867.txt- Nortel Networks
../data/rfc/rfc2867.txt- June 2000
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt: RADIUS Accounting Modifications for Tunnel Protocol Support
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-Status of this Memo
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- This memo provides information for the Internet community. It does
../data/rfc/rfc2867.txt- not specify an Internet standard of any kind. Distribution of this
--
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- Copyright (C) The Internet Society (2000). All Rights Reserved.
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-Abstract
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt: This document defines new RADIUS accounting Attributes and new values
../data/rfc/rfc2867.txt- for the existing Acct-Status-Type Attribute [1] designed to support
../data/rfc/rfc2867.txt- the provision of compulsory tunneling in dial-up networks.
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-Specification of Requirements
../data/rfc/rfc2867.txt-
--
../data/rfc/rfc2867.txt- involve compulsory tunneling: the tunnel is created without any
../data/rfc/rfc2867.txt- action from the user and without allowing the user any choice in the
../data/rfc/rfc2867.txt- matter, as a service of the Internet service provider (ISP).
../data/rfc/rfc2867.txt- Typically, ISPs providing a service want to collect data regarding
../data/rfc/rfc2867.txt- that service for billing, network planning, etc. One way to collect
../data/rfc/rfc2867.txt: usage data in dial-up networks is by means of RADIUS Accounting [1].
../data/rfc/rfc2867.txt: The use of RADIUS Accounting allows dial-up usage data to be
../data/rfc/rfc2867.txt- collected at a central location, rather than stored on each NAS.
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-Zorn, et al. Informational [Page 1]
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt:RFC 2867 RADIUS Tunnel Accounting Support June 2000
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- In order to collect usage data regarding tunneling, new RADIUS
../data/rfc/rfc2867.txt- attributes are needed; this document defines these attributes. In
../data/rfc/rfc2867.txt- addition, several new values for the Acct-Status-Type attribute are
--
../data/rfc/rfc2867.txt- Compulsory tunneling may be part of a package of services provided by
../data/rfc/rfc2867.txt- one entity to another. For example, a corporation might contract
../data/rfc/rfc2867.txt- with an ISP to provide remote intranet access to its employees via
../data/rfc/rfc2867.txt- compulsory tunneling. In this case, the integration of RADIUS and
../data/rfc/rfc2867.txt- tunnel protocols allows the ISP and the corporation to synchronize
../data/rfc/rfc2867.txt: their accounting activities so that each side receives a record of
../data/rfc/rfc2867.txt- the user's resource consumption. This provides the corporation with
../data/rfc/rfc2867.txt- the means to audit ISP bills.
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- In auditing, the User-Name, Acct-Tunnel-Connection, Tunnel-Client-
../data/rfc/rfc2867.txt- Endpoint and Tunnel-Server-Endpoint attributes are typically used to
../data/rfc/rfc2867.txt: uniquely identify the call, allowing the Accounting-Request sent by
../data/rfc/rfc2867.txt: the NAS to be reconciled with the corresponding Accounting-Request
../data/rfc/rfc2867.txt- sent by the tunnel server.
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt: When implementing RADIUS accounting for L2TP/PPTP tunneling, the
../data/rfc/rfc2867.txt- Call-Serial-Number SHOULD be used in the Acct-Tunnel-Connection
../data/rfc/rfc2867.txt- attribute. In L2TP, the Call-Serial-Number is a 32-bit field and in
../data/rfc/rfc2867.txt- PPTP it is a 16-bit field. In PPTP the combination of IP Address and
../data/rfc/rfc2867.txt- Call-Serial-Number SHOULD be unique, but this is not required. In
../data/rfc/rfc2867.txt- addition, no method for determining the Call-Serial-Number is
--
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-Zorn, et al. Informational [Page 2]
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt:RFC 2867 RADIUS Tunnel Accounting Support June 2000
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- Description
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- This value MAY be used to mark the establishment of a tunnel
../data/rfc/rfc2867.txt- with another node. If this value is used, the following
../data/rfc/rfc2867.txt: attributes SHOULD also be included in the Accounting-Request
../data/rfc/rfc2867.txt- packet:
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- User-Name (1)
../data/rfc/rfc2867.txt- NAS-IP-Address (4)
../data/rfc/rfc2867.txt- Acct-Delay-Time (41)
--
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- Description
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- This value MAY be used to mark the destruction of a tunnel to
../data/rfc/rfc2867.txt- or from another node. If this value is used, the following
../data/rfc/rfc2867.txt: attributes SHOULD also be included in the Accounting-Request
../data/rfc/rfc2867.txt- packet:
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- User-Name (1)
../data/rfc/rfc2867.txt- NAS-IP-Address (4)
../data/rfc/rfc2867.txt- Acct-Delay-Time (41)
--
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-Zorn, et al. Informational [Page 3]
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt:RFC 2867 RADIUS Tunnel Accounting Support June 2000
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-3.3. Tunnel-Reject
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- Value
--
../data/rfc/rfc2867.txt- Description
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- This value MAY be used to mark the rejection of the
../data/rfc/rfc2867.txt- establishment of a tunnel with another node. If this value is
../data/rfc/rfc2867.txt- used, the following attributes SHOULD also be included in the
../data/rfc/rfc2867.txt: Accounting-Request packet:
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- User-Name (1)
../data/rfc/rfc2867.txt- NAS-IP-Address (4)
../data/rfc/rfc2867.txt- Acct-Delay-Time (41)
../data/rfc/rfc2867.txt- Acct-Terminate-Cause (49)
--
../data/rfc/rfc2867.txt- This value MAY be used to mark the creation of a tunnel link.
../data/rfc/rfc2867.txt- Only some tunnel types (e.g., L2TP) support multiple links per
../data/rfc/rfc2867.txt- tunnel. This Attribute is intended to mark the creation of a
../data/rfc/rfc2867.txt- link within a tunnel that carries multiple links. For example,
../data/rfc/rfc2867.txt- if a mandatory tunnel were to carry M links over its lifetime,
../data/rfc/rfc2867.txt: 2(M+1) RADIUS Accounting messages might be sent: one each
../data/rfc/rfc2867.txt- marking the initiation and destruction of the tunnel itself and
../data/rfc/rfc2867.txt- one each for the initiation and destruction of each link within
../data/rfc/rfc2867.txt- the tunnel. If only a single link can be carried in a given
../data/rfc/rfc2867.txt- tunnel (e.g., IPsec in the tunnel mode), this Attribute need
../data/rfc/rfc2867.txt: not be included in accounting packets, since the presence of
../data/rfc/rfc2867.txt- the Tunnel-Start Attribute will imply the initiation of the
../data/rfc/rfc2867.txt- (only possible) link.
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-Zorn, et al. Informational [Page 4]
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt:RFC 2867 RADIUS Tunnel Accounting Support June 2000
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- If this value is used, the following attributes SHOULD also be
../data/rfc/rfc2867.txt: included in the Accounting-Request packet:
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- User-Name (1)
../data/rfc/rfc2867.txt- NAS-IP-Address (4)
../data/rfc/rfc2867.txt- NAS-Port (5)
../data/rfc/rfc2867.txt- Acct-Delay-Time (41)
--
../data/rfc/rfc2867.txt- This value MAY be used to mark the destruction of a tunnel
../data/rfc/rfc2867.txt- link. Only some tunnel types (e.g., L2TP) support multiple
../data/rfc/rfc2867.txt- links per tunnel. This Attribute is intended to mark the
../data/rfc/rfc2867.txt- destruction of a link within a tunnel that carries multiple
../data/rfc/rfc2867.txt- links. For example, if a mandatory tunnel were to carry M
../data/rfc/rfc2867.txt: links over its lifetime, 2(M+1) RADIUS Accounting messages
../data/rfc/rfc2867.txt- might be sent: one each marking the initiation and destruction
../data/rfc/rfc2867.txt- of the tunnel itself and one each for the initiation and
../data/rfc/rfc2867.txt- destruction of each link within the tunnel. If only a single
../data/rfc/rfc2867.txt- link can be carried in a given tunnel (e.g., IPsec in the
../data/rfc/rfc2867.txt: tunnel mode), this Attribute need not be included in accounting
../data/rfc/rfc2867.txt- packets, since the presence of the Tunnel-Stop Attribute will
../data/rfc/rfc2867.txt- imply the termination of the (only possible) link.
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- If this value is used, the following attributes SHOULD also be
../data/rfc/rfc2867.txt: included in the Accounting-Request packet:
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- User-Name (1)
../data/rfc/rfc2867.txt- NAS-IP-Address (4)
../data/rfc/rfc2867.txt- NAS-Port (5)
../data/rfc/rfc2867.txt- Acct-Delay-Time (41)
--
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-Zorn, et al. Informational [Page 5]
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt:RFC 2867 RADIUS Tunnel Accounting Support June 2000
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- Acct-Output-Packets (48)
../data/rfc/rfc2867.txt- Acct-Terminate-Cause (49)
../data/rfc/rfc2867.txt- Acct-Multi-Session-Id (51)
--
../data/rfc/rfc2867.txt- This value MAY be used to mark the rejection of the
../data/rfc/rfc2867.txt- establishment of a new link in an existing tunnel. Only some
../data/rfc/rfc2867.txt- tunnel types (e.g., L2TP) support multiple links per tunnel.
../data/rfc/rfc2867.txt- If only a single link can be carried in a given tunnel (e.g.,
../data/rfc/rfc2867.txt- IPsec in the tunnel mode), this Attribute need not be included
../data/rfc/rfc2867.txt: in accounting packets, since in this case the Tunnel-Reject
../data/rfc/rfc2867.txt- Attribute has the same meaning.
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- If this value is used, the following attributes SHOULD also be
../data/rfc/rfc2867.txt: included in the Accounting-Request packet:
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- User-Name (1)
../data/rfc/rfc2867.txt- NAS-IP-Address (4)
../data/rfc/rfc2867.txt- Acct-Delay-Time (41)
../data/rfc/rfc2867.txt- Acct-Terminate-Cause (49)
--
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-Zorn, et al. Informational [Page 6]
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt:RFC 2867 RADIUS Tunnel Accounting Support June 2000
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-4. Attributes
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-4.1. Acct-Tunnel-Connection
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- Description
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- This Attribute indicates the identifier assigned to the tunnel
../data/rfc/rfc2867.txt: session. It SHOULD be included in Accounting-Request packets
../data/rfc/rfc2867.txt- which contain an Acct-Status-Type attribute having the value
../data/rfc/rfc2867.txt- Start, Stop or any of the values described above. This
../data/rfc/rfc2867.txt- attribute, along with the Tunnel-Client-Endpoint and Tunnel-
../data/rfc/rfc2867.txt- Server-Endpoint attributes [3], may be used to provide a means
../data/rfc/rfc2867.txt- to uniquely identify a tunnel session for auditing purposes.
--
../data/rfc/rfc2867.txt-4.2. Acct-Tunnel-Packets-Lost
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- Description
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- This Attribute indicates the number of packets lost on a given
../data/rfc/rfc2867.txt: link. It SHOULD be included in Accounting-Request packets
../data/rfc/rfc2867.txt- which contain an Acct-Status-Type attribute having the value
../data/rfc/rfc2867.txt- Tunnel-Link-Stop.
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-Zorn, et al. Informational [Page 7]
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt:RFC 2867 RADIUS Tunnel Accounting Support June 2000
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- A summary of the Acct-Tunnel-Packets-Lost Attribute format is
../data/rfc/rfc2867.txt- shown below. The fields are transmitted from left to right.
../data/rfc/rfc2867.txt-
--
../data/rfc/rfc2867.txt- of packets lost on the link.
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-5. Table of Attributes
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- The following table provides a guide to which attributes may be found
../data/rfc/rfc2867.txt: in Accounting-Request packets. No tunnel attributes should be found
../data/rfc/rfc2867.txt: in Accounting-Response packets.
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- Request # Attribute
../data/rfc/rfc2867.txt- 0-1 64 Tunnel-Type
../data/rfc/rfc2867.txt- 0-1 65 Tunnel-Medium-Type
../data/rfc/rfc2867.txt- 0-1 66 Tunnel-Client-Endpoint
--
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-Zorn, et al. Informational [Page 8]
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt:RFC 2867 RADIUS Tunnel Accounting Support June 2000
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- The following table defines the meaning of the above table entries.
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- 0 This attribute MUST NOT be present in packet.
--
../data/rfc/rfc2867.txt- 0-1 Zero or one instance of this attribute MAY be present in
../data/rfc/rfc2867.txt- packet.
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-6. Security Considerations
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt: By "sniffing" RADIUS Accounting packets, it might be possible for an
../data/rfc/rfc2867.txt- eavesdropper to perform a passive analysis of tunnel connections.
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-7. References
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt: [1] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
../data/rfc/rfc2867.txt- Levels", BCP 14, RFC 2119, March 1997.
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- [3] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and
--
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-Zorn, et al. Informational [Page 9]
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt:RFC 2867 RADIUS Tunnel Accounting Support June 2000
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-9. Authors' Addresses
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- Questions about this memo can be directed to:
--
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-Zorn, et al. Informational [Page 10]
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt:RFC 2867 RADIUS Tunnel Accounting Support June 2000
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt-10. Full Copyright Statement
../data/rfc/rfc2867.txt-
../data/rfc/rfc2867.txt- Copyright (C) The Internet Society (2000). All Rights Reserved.
--
../data/rfc/rfc4283.txt- The capability to identify a mobility entity via identifiers other
../data/rfc/rfc4283.txt- than the IPv6 address can be leveraged for performing various
../data/rfc/rfc4283.txt- functions, for example,
../data/rfc/rfc4283.txt-
../data/rfc/rfc4283.txt- o authentication and authorization using an existing AAA
../data/rfc/rfc4283.txt: (Authentication, Authorization, and Accounting) infrastructure or
../data/rfc/rfc4283.txt- via an HLR/AuC (Home Location Register/Authentication Center)
../data/rfc/rfc4283.txt-
../data/rfc/rfc4283.txt- o dynamic allocation of a mobility anchor point
../data/rfc/rfc4283.txt-
../data/rfc/rfc4283.txt- o dynamic allocation of a home address
--
../data/rfc/rfc4283.txt-
../data/rfc/rfc4283.txt- This option SHOULD be used when Internet Key Exchange (IKE)/IPsec is
../data/rfc/rfc4283.txt- not used for protecting binding updates or binding acknowledgements
../data/rfc/rfc4283.txt- as specified in [RFC3775]. It is typically used with the
../data/rfc/rfc4283.txt- authentication option [RFC4285]. But this option may be used
../data/rfc/rfc4283.txt: independently. For example, the identifier can provide accounting
../data/rfc/rfc4283.txt- and billing services.
../data/rfc/rfc4283.txt-
../data/rfc/rfc4283.txt-
../data/rfc/rfc4283.txt-
../data/rfc/rfc4283.txt-
--
../data/rfc/rfc758.txt- 1 1 Reserved
../data/rfc/rfc758.txt- 2-71 2-107 AHHP Regular Messages [1,3]
../data/rfc/rfc758.txt- 72-151 110-227 Reserved
../data/rfc/rfc758.txt- 152 230 PARC Universal Protocol
../data/rfc/rfc758.txt- 153 231 TIP Status Reporting
../data/rfc/rfc758.txt: 154 232 TIP Accounting
../data/rfc/rfc758.txt- 155-158 233-236 Internet Protocol [44]
../data/rfc/rfc758.txt- 159-191 237-277 Measurements [28]
../data/rfc/rfc758.txt- 192-195 300-303 Message Switching Protocol [4,5]
../data/rfc/rfc758.txt- 196-255 304-377 Experimental Protocols
../data/rfc/rfc758.txt- 224-255 340-377 NVP [1,39]
--
../data/rfc/rfc3334.txt-Category: Experimental G. Carle
../data/rfc/rfc3334.txt- Fraunhofer FOKUS
../data/rfc/rfc3334.txt- October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: Policy-Based Accounting
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Status of this Memo
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- This memo defines an Experimental Protocol for the Internet
../data/rfc/rfc3334.txt- community. It does not specify an Internet standard of any kind.
--
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- Copyright (C) The Internet Society (2002). All Rights Reserved.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Abstract
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: This document describes policy-based accounting which is an approach
../data/rfc/rfc3334.txt: to provide flexibility to accounting architectures. Accounting
../data/rfc/rfc3334.txt: policies describe the configuration of an accounting architecture in
../data/rfc/rfc3334.txt: a standardized way. They are used to instrument the accounting
../data/rfc/rfc3334.txt- architecture and can be exchanged between Authentication,
../data/rfc/rfc3334.txt: Authorization and Accounting (AAA) entities in order to share
../data/rfc/rfc3334.txt- configuration information.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- This document describes building blocks and message sequences for
../data/rfc/rfc3334.txt: policy-based accounting in the generic AAA architecture (RFC 2903).
../data/rfc/rfc3334.txt: Examples are given for the usage of accounting policies in different
../data/rfc/rfc3334.txt: scenarios. It is also shown how accounting components can be
../data/rfc/rfc3334.txt- integrated into the AAA authorization framework (RFC 2904). This
../data/rfc/rfc3334.txt- document does not propose a language for the description of
../data/rfc/rfc3334.txt: accounting policies. Rather, it is assumed that a suitable policy
../data/rfc/rfc3334.txt- language can be chosen from existing or upcoming standards.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Table of Contents
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- 1. Introduction...............................................2
../data/rfc/rfc3334.txt- 1.1 Motivation.................................................2
../data/rfc/rfc3334.txt- 1.2 Document Scope.............................................3
../data/rfc/rfc3334.txt- 2. Terminology................................................4
../data/rfc/rfc3334.txt: 3. Impact of Provider Network Characteristics on Accounting...7
../data/rfc/rfc3334.txt- 4. Business roles and relations...............................8
../data/rfc/rfc3334.txt- 5. Reference Model and Building Blocks.......................11
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 1]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: 6. Accounting Policies.......................................14
../data/rfc/rfc3334.txt: 6.1 Accounting Policy Condition...............................15
../data/rfc/rfc3334.txt: 6.2 Accounting Policy Action..................................16
../data/rfc/rfc3334.txt- 6.3 Example for Meter Configuration...........................17
../data/rfc/rfc3334.txt: 7. Accounting Services.......................................19
../data/rfc/rfc3334.txt: 7.1 Integrated Accounting.....................................19
../data/rfc/rfc3334.txt: 7.2 Discrete Accounting.......................................21
../data/rfc/rfc3334.txt: 7.3 Intra-Domain Accounting...................................22
../data/rfc/rfc3334.txt: 7.4 Inter-Domain Accounting...................................23
../data/rfc/rfc3334.txt: 8. Accounting with different Authorization Models............25
../data/rfc/rfc3334.txt- 8.1 Agent Sequence............................................25
../data/rfc/rfc3334.txt- 8.2 Pull Sequence.............................................26
../data/rfc/rfc3334.txt- 8.3 Push Sequence.............................................27
../data/rfc/rfc3334.txt- 8.4 Roaming...................................................28
../data/rfc/rfc3334.txt- 9. Examples..................................................29
../data/rfc/rfc3334.txt- 9.1 Printing Service Example..................................29
../data/rfc/rfc3334.txt: 9.1.1 Intra-Domain Accounting...................................29
../data/rfc/rfc3334.txt: 9.1.2 Inter-Domain Accounting...................................30
../data/rfc/rfc3334.txt: 9.1.3 User Accounting Indication................................31
../data/rfc/rfc3334.txt- 9.2 Mobile/Roaming Example....................................31
../data/rfc/rfc3334.txt- 9.3 Diffserv Example..........................................33
../data/rfc/rfc3334.txt: 9.4 User Accounting Indication Example........................37
../data/rfc/rfc3334.txt- 10. Security Considerations...................................39
../data/rfc/rfc3334.txt- 11. References................................................41
../data/rfc/rfc3334.txt- 12. Acknowledgments...........................................42
../data/rfc/rfc3334.txt- Author's Addresses..............................................43
../data/rfc/rfc3334.txt- Full Copyright Statement........................................44
--
../data/rfc/rfc3334.txt- the ability of the user to give a good prediction of the expected
../data/rfc/rfc3334.txt- traffic characteristics. This can be extenuated by using a charging
../data/rfc/rfc3334.txt- scheme that is based on both the reserved and the used resources. In
../data/rfc/rfc3334.txt- order to support usage-based charging, the collection of information
../data/rfc/rfc3334.txt- about the resource reservation and utilization is required. The
../data/rfc/rfc3334.txt: collection of data about resource usage is called accounting.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 2]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- Service providers have various options for service differentiation,
../data/rfc/rfc3334.txt: charging schemes and the provisioning of accounting services. The
../data/rfc/rfc3334.txt- applied charging schemes for the provided services are one
../data/rfc/rfc3334.txt- significant feature used by providers to distinguish themselves from
../data/rfc/rfc3334.txt- competitors. Therefore, providers use different charging schemes and
../data/rfc/rfc3334.txt- may change the schemes in accordance with their business plan.
../data/rfc/rfc3334.txt: Providers can also offer different accounting services (e.g.
../data/rfc/rfc3334.txt- standard, comprehensive, etc.) in order to allow customers/users to
../data/rfc/rfc3334.txt- choose one scheme that meets the customers/users needs. Furthermore,
../data/rfc/rfc3334.txt: it may be advantageous for a provider to outsource accounting
../data/rfc/rfc3334.txt- functionality to a third party. Users introduce various traffic
../data/rfc/rfc3334.txt: profiles and may have individual preferences regarding accounting
../data/rfc/rfc3334.txt: services (like itemized invoices, accounting indications, spending
../data/rfc/rfc3334.txt- limits etc.).
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: One further challenge for the configuration of accounting services
../data/rfc/rfc3334.txt: are heterogeneous metering and accounting infrastructures within
../data/rfc/rfc3334.txt: provider domains. Also, the usage of different accounting and
../data/rfc/rfc3334.txt- metering solutions used in different provider networks complicates
../data/rfc/rfc3334.txt- the sharing of configuration parameters (e.g. in roaming scenarios).
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: The configuration and dynamic adaptation of the accounting process to
../data/rfc/rfc3334.txt- the business model and specific user demands requires a flexible
../data/rfc/rfc3334.txt: configurable accounting infrastructure. The utilization of
../data/rfc/rfc3334.txt- standardized policies for the expression of conditions and related
../data/rfc/rfc3334.txt- configuration actions also allows the configuration of heterogeneous
../data/rfc/rfc3334.txt: infrastructures. For this purpose we propose to use accounting
../data/rfc/rfc3334.txt: policies to configure the accounting infrastructure and use the
../data/rfc/rfc3334.txt: Authentication, Authorization and Accounting (AAA) architecture to
../data/rfc/rfc3334.txt- exchange and to deploy these policies.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-1.2 Document Scope
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: This document describes the structure and usage of accounting
../data/rfc/rfc3334.txt- policies. It shows how the characteristics of the provider network
../data/rfc/rfc3334.txt: influence the requirements for accounting. The relations between the
../data/rfc/rfc3334.txt: different roles that are involved in the accounting process and the
../data/rfc/rfc3334.txt: required building blocks for an accounting architecture are
../data/rfc/rfc3334.txt- introduced. This document describes an architecture and mechanisms
../data/rfc/rfc3334.txt: to configure the accounting service. It proposes to use the AAA
../data/rfc/rfc3334.txt: protocol for the exchange of accounting configuration information
../data/rfc/rfc3334.txt- expressed in policies. It does not propose a specific protocol for
../data/rfc/rfc3334.txt: the accounting configuration itself. The configuration itself can be
../data/rfc/rfc3334.txt- done by existing protocols (e.g. Common Open Policy Service Protocol
../data/rfc/rfc3334.txt- for Support of Policy Provisioning - COPS-PR, Simple Network
../data/rfc/rfc3334.txt- Management Protocol - SNMP, etc.). Furthermore, it is shown how
../data/rfc/rfc3334.txt: different accounting services can be provided in intra- and inter-
../data/rfc/rfc3334.txt: domain scenarios. Examples are given for the usage of accounting
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 3]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: policies in different scenarios. They show how accounting components
../data/rfc/rfc3334.txt- can be integrated into the authorization framework proposed in
../data/rfc/rfc3334.txt- [RFC2904].
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: Accounting management architectures and objectives as well as the
../data/rfc/rfc3334.txt: transport of accounting records are discussed in [RFC2975] and are
../data/rfc/rfc3334.txt- not further explained here. This document focuses on the
../data/rfc/rfc3334.txt: configuration of the accounting architecture and measurement devices.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: The policy-based accounting architecture represented in this document
../data/rfc/rfc3334.txt: describes policy-based accounting from the perspective of a Generic
../data/rfc/rfc3334.txt- AAA Server [RFC2903]. Such a server combines into a single entity
../data/rfc/rfc3334.txt: the functions of managing accounting policy, together with the
../data/rfc/rfc3334.txt- functions of managing user-specific authentication, authorization and
../data/rfc/rfc3334.txt- service provisioning. Some service providers may choose to implement
../data/rfc/rfc3334.txt- an approach that does not combine these functions into a single
../data/rfc/rfc3334.txt- entity or protocol, in which case that particular aspect of this
../data/rfc/rfc3334.txt- architecture does not apply.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- This document does not propose a language for the description of
../data/rfc/rfc3334.txt: accounting policies. It is rather assumed that a suitable policy
../data/rfc/rfc3334.txt- language can be chosen from existing or upcoming standards.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-2. Terminology
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: Accounting Indication/Confirmation
../data/rfc/rfc3334.txt: Accounting indication messages are pushed from the
../data/rfc/rfc3334.txt: originating AAA server (the server where the accounting
../data/rfc/rfc3334.txt- information was generated) to the recipient which can be an
../data/rfc/rfc3334.txt: AAA server or a customer/user application. Accounting
../data/rfc/rfc3334.txt: indications contain accounting records which describe the
../data/rfc/rfc3334.txt: resource consumption for a service. Accounting indication
../data/rfc/rfc3334.txt- messages can also contain aggregated information for multiple
../data/rfc/rfc3334.txt: services. There can be interim and end-of-session accounting
../data/rfc/rfc3334.txt- indication messages. Interim indications are delivered in
../data/rfc/rfc3334.txt- specified intervals to the recipient during the service
../data/rfc/rfc3334.txt- session while end-of-session indications are given to the
../data/rfc/rfc3334.txt: recipient at the end of the session only. Accounting
../data/rfc/rfc3334.txt: indications may be acknowledged by accounting confirmations
../data/rfc/rfc3334.txt- to provide application layer reliability.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: Accounting Policy Indication/Confirmation
../data/rfc/rfc3334.txt: Accounting policy indication messages contain accounting
../data/rfc/rfc3334.txt- policies and are sent from a customer/user or a AAA server to
../data/rfc/rfc3334.txt: another AAA server. Accounting policy indications may be
../data/rfc/rfc3334.txt: acknowledged by accounting policy confirmations to provide
../data/rfc/rfc3334.txt- application layer reliability.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 4]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: Accounting Request/Answer
../data/rfc/rfc3334.txt: Accounting requests are sent by an AAA server to another AAA
../data/rfc/rfc3334.txt: server to request the current accounting information for a
../data/rfc/rfc3334.txt- particular session set (polling). The request is answered
../data/rfc/rfc3334.txt: with an accounting answer which contains the accounting
../data/rfc/rfc3334.txt- records.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: Accounting Policy Request/Answer
../data/rfc/rfc3334.txt: Accounting policy requests are sent by an AAA server to
../data/rfc/rfc3334.txt: another AAA server or a customer/user to request accounting
../data/rfc/rfc3334.txt- policies for a service. The request is answered by an
../data/rfc/rfc3334.txt: accounting policy answer that contains the accounting policy.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: Accounting Policies
../data/rfc/rfc3334.txt: Accounting policies describe rules for generation, transport
../data/rfc/rfc3334.txt: and storage of accounting data. These rules are used for the
../data/rfc/rfc3334.txt: configuration of the accounting process.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- Application Specific Module (ASM)
../data/rfc/rfc3334.txt- An ASM provides the functionalities required for the user
../data/rfc/rfc3334.txt- configuration of a service to an authenticated and authorized
../data/rfc/rfc3334.txt- user. It gets application specific information (ASI) (e.g.
--
../data/rfc/rfc3334.txt- A charging scheme is an instruction for calculating a charge.
../data/rfc/rfc3334.txt- Usually, a charging scheme is represented by a formula that
../data/rfc/rfc3334.txt- consists of charging variables (e.g. volume, time, reserved
../data/rfc/rfc3334.txt- peak rate) and charging coefficients (e.g. price per time
../data/rfc/rfc3334.txt- unit). The charging variables are usually filled by
../data/rfc/rfc3334.txt: information from accounting data.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- Classifier
../data/rfc/rfc3334.txt- This document uses the definition of classifier as given in
../data/rfc/rfc3334.txt- [RFC2475]. Since this document assumes that meters already
../data/rfc/rfc3334.txt- include classification functions, the term classifier is only
--
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 5]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- Meter
../data/rfc/rfc3334.txt- This document uses the definition of meter as given in
../data/rfc/rfc3334.txt- [RFC2722]. This meter definition already includes the
--
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 6]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:3. Impact of Provider Network Characteristics on Accounting
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- There are many options for future service providers for the
../data/rfc/rfc3334.txt- realization of service differentiation and provisioning. Therefore,
../data/rfc/rfc3334.txt- provider networks can vary with respect to several characteristics
../data/rfc/rfc3334.txt: that impact accounting and charging:
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- - Size and Purpose
../data/rfc/rfc3334.txt- A small ISP that deals with individual customers may charge
../data/rfc/rfc3334.txt- individual users based on single flows. Backbone operators often
../data/rfc/rfc3334.txt- have small ISPs and large corporations as customers, and usually
../data/rfc/rfc3334.txt- charge based on traffic aggregates instead of individual flows.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- - QoS provisioning technique
../data/rfc/rfc3334.txt: Diffserv accounting requirements differ from Intserv accounting
../data/rfc/rfc3334.txt- requirements (e.g. meter granularity).
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- - Service classes
../data/rfc/rfc3334.txt- The definition of service classes within a network and the degree of
../data/rfc/rfc3334.txt- freedom that customers are given (e.g. gold/silver/bronze service vs.
../data/rfc/rfc3334.txt- a free choice of individual traffic profile parameters) is important,
../data/rfc/rfc3334.txt- e.g. for the flow classification within the network, and influences
../data/rfc/rfc3334.txt: the accounting functions required.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- - Charging scheme
../data/rfc/rfc3334.txt- There exists a wide variety of charging schemes using tariff
../data/rfc/rfc3334.txt- variables based on different technical and/or economic models. The
../data/rfc/rfc3334.txt: chosen charging scheme(s) influence the accounting requirements for
../data/rfc/rfc3334.txt- the provider. While some charging schemes lead to zero or only few
../data/rfc/rfc3334.txt: accounting requirements, other charging schemes may be highly
../data/rfc/rfc3334.txt- demanding. For instance, flat rate charging schemes require no
../data/rfc/rfc3334.txt: accounting infrastructure at all. In contrast to this, volume-based
../data/rfc/rfc3334.txt- charging schemes require the measurement of the transmitted volume
../data/rfc/rfc3334.txt: and, with this, increases the complexity for accounting. Tariffs
../data/rfc/rfc3334.txt- that introduce variable prices may require to provide the users
../data/rfc/rfc3334.txt: regularly with accounting information (e.g. by interim accounting
../data/rfc/rfc3334.txt- indications).
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: - Accounting Services
../data/rfc/rfc3334.txt: Providers may offer different accounting services (e.g. accounting
../data/rfc/rfc3334.txt- indication, itemized invoice, etc.)
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: - Accounting agreements with other providers
../data/rfc/rfc3334.txt- Providers may have agreements with other providers in order to share
../data/rfc/rfc3334.txt: accounting tasks and distribute accounting data so that, e.g.,
../data/rfc/rfc3334.txt- metering need only be done once. If so, it may be useful if
../data/rfc/rfc3334.txt: providers can not only exchange accounting data, but also information
../data/rfc/rfc3334.txt: on the configuration of accounting modules (e.g. meters). It is
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 7]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: important for providers to agree beforehand how accounting data will
../data/rfc/rfc3334.txt: be collected and monitored, and how disputes concerning accounting
../data/rfc/rfc3334.txt- data will be resolved. In order to minimize disputes between
../data/rfc/rfc3334.txt- providers, it is important for them to agree that either both will
../data/rfc/rfc3334.txt: collect accounting data - and will compare it with the other's data
../data/rfc/rfc3334.txt- at regular intervals, e.g. monthly - or both will use a single source
../data/rfc/rfc3334.txt: of accounting data provided by one of them (or by a trusted third
../data/rfc/rfc3334.txt- party).
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- - Exploiting Capabilities of Existing Infrastructure (meters, data
../data/rfc/rfc3334.txt- collection points)
../data/rfc/rfc3334.txt- Providers may already have functions within the network that can
../data/rfc/rfc3334.txt: provide accounting functions (e.g. MIB objects, profile meters,
../data/rfc/rfc3334.txt: proprietary accounting solutions). In order to avoid duplicated
../data/rfc/rfc3334.txt: functionality, it should be possible to use these accounting
../data/rfc/rfc3334.txt- resources. Therefore, the configuration of different types of
../data/rfc/rfc3334.txt: accounting modules (e.g. meters) should be possible. A common
../data/rfc/rfc3334.txt: language to express accounting module configurations would be useful
../data/rfc/rfc3334.txt- for this purpose.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-4. Business roles and relations
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- In investigating service provisions in the current and forthcoming
--
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 8]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- Error Correction - FEC). A transport service might also
../data/rfc/rfc3334.txt- include mechanisms on other layers for improving the transport
../data/rfc/rfc3334.txt- (e.g. MPLS).
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- - Management services are responsible for the management of
../data/rfc/rfc3334.txt: resources (e.g. configuration, accounting, security).
../data/rfc/rfc3334.txt: Accounting services describe the provisioning of data about the
../data/rfc/rfc3334.txt: current or previous resource reservation and usage. Accounting
../data/rfc/rfc3334.txt- services are needed by providers to generate a bill or by users
../data/rfc/rfc3334.txt- to monitor their resource usage.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- - Service Subscriber
../data/rfc/rfc3334.txt- The service subscriber is the entity that has subscribed to a service
--
../data/rfc/rfc3334.txt- network of a network provider is probably not a global network which
../data/rfc/rfc3334.txt- connects all subscribers, providers and brokers. The transport
../data/rfc/rfc3334.txt- network is segmented into a number of sub-networks or domains
../data/rfc/rfc3334.txt- controlled by different network providers with business relations
../data/rfc/rfc3334.txt- existing between them. Each domain is responsible for intra-domain
../data/rfc/rfc3334.txt: management and accounting. For inter-domain management and
../data/rfc/rfc3334.txt: accounting, appropriate communication interfaces between network
../data/rfc/rfc3334.txt- providers must exist.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- - Service Provider
../data/rfc/rfc3334.txt- A service provider entity provides a service. A service provider can
../data/rfc/rfc3334.txt- offer a service directly to the service subscriber/user. A service
--
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 9]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- other service providers, subscribers, brokers and network providers.
../data/rfc/rfc3334.txt- A service provider provides information services on top of transport
../data/rfc/rfc3334.txt- services provided by network providers.
--
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 10]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- The following examples show how this business relationship model can
../data/rfc/rfc3334.txt- be applied to different services.
../data/rfc/rfc3334.txt-
--
../data/rfc/rfc3334.txt- get a reference to appropriate network providers.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-5. Reference Model and Building Blocks
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- We have developed a reference model for describing the interactions
../data/rfc/rfc3334.txt: between the different metering, accounting and charging processes and
../data/rfc/rfc3334.txt- their configuration via policies. This reference model is shown in
../data/rfc/rfc3334.txt- Figure 2. At the right side, five layers show the different building
../data/rfc/rfc3334.txt- blocks. The blocks are layered according to the processing of the
../data/rfc/rfc3334.txt: data from the bottom level metering via accounting, up to the final
../data/rfc/rfc3334.txt- billing process. Data aggregation is not only done at the collection
../data/rfc/rfc3334.txt- layer, it can also be done at the other layers. The building blocks
../data/rfc/rfc3334.txt- on the different layers are configured through the policies shown on
../data/rfc/rfc3334.txt- the left side. Higher layer policies can be translated into lower
../data/rfc/rfc3334.txt- layer policies. The configuration parameters are extracted from the
--
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 11]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- distinguished: Static meters and configurable meters. In the case of
../data/rfc/rfc3334.txt- static meters, all flows are measured with a fixed granularity, not
../data/rfc/rfc3334.txt- distinguishing if a subsequent charging process needs the specific
--
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- - Collection
../data/rfc/rfc3334.txt- The data gathered by the meter(s) has to be collected for further
../data/rfc/rfc3334.txt- processing. Collection of meter data can be initiated by the meter
../data/rfc/rfc3334.txt- itself (push model) or by a collector entity (pull model). Collected
../data/rfc/rfc3334.txt: data can be aggregated before being passed to the accounting layer.
../data/rfc/rfc3334.txt- Metering policies define how collection and aggregation is done.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
--
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 12]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- POLICY CONFIGURATION BUILDING BLOCKS
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- +---------------+ +-------------------------+
--
../data/rfc/rfc3334.txt- | |------------------>| Charging |
../data/rfc/rfc3334.txt- +---------------+ +-------------------------+
../data/rfc/rfc3334.txt- | ^ acct
../data/rfc/rfc3334.txt- V | data
../data/rfc/rfc3334.txt- +---------------+ +-------------------------+
../data/rfc/rfc3334.txt: | Accounting | | |
../data/rfc/rfc3334.txt: | |------------------>| Accounting |
../data/rfc/rfc3334.txt- +---------------+ +-------------------------+
../data/rfc/rfc3334.txt- | ^ aggr. meter
../data/rfc/rfc3334.txt- V | data
../data/rfc/rfc3334.txt- +---------------+ +-------------------------+
../data/rfc/rfc3334.txt- | |------------------>| Collection |
--
../data/rfc/rfc3334.txt- | |------------------>| Metering |
../data/rfc/rfc3334.txt- +---------------+ +-------------------------+
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- Figure 2: Reference Model
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: - Accounting
../data/rfc/rfc3334.txt: Accounting describes the collection of data about resource
../data/rfc/rfc3334.txt- consumption. This includes the control of data gathering (via
../data/rfc/rfc3334.txt: metering), transport and storage of accounting data. For subsequent
../data/rfc/rfc3334.txt- charging, the metered data must be associated with a user that is the
../data/rfc/rfc3334.txt- initiator of a flow and a customer (service subscriber) that is
../data/rfc/rfc3334.txt: responsible for payment. For initiation of an accounting process, a
../data/rfc/rfc3334.txt- user or foreign provider must be authenticated and authorized. These
../data/rfc/rfc3334.txt: three functions can be performed by the AAA server. The accounting
../data/rfc/rfc3334.txt: process is configured through accounting policies.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- - Charging
../data/rfc/rfc3334.txt: Charging derives non-monetary costs for accounting data sets based on
../data/rfc/rfc3334.txt- service and customer specific tariff parameters. Different cost
../data/rfc/rfc3334.txt: metrics may be applied to the same accounting records even in
../data/rfc/rfc3334.txt- parallel. Charging policies define the tariffs and parameters which
../data/rfc/rfc3334.txt- are applied.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 13]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- - Billing
../data/rfc/rfc3334.txt- Billing translates costs calculated by the Charging into monetary
../data/rfc/rfc3334.txt- units and generates a final bill for the customer. Billing policies
--
../data/rfc/rfc3334.txt- the bill (e.g. itemized or not, partial anyomization, etc.) and the
../data/rfc/rfc3334.txt- time for billing (e.g. weekly, monthly, etc.).
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- We propose to use policies expressed in a standardized way to
../data/rfc/rfc3334.txt- appropriately configure the meter, meter data collection and
../data/rfc/rfc3334.txt: accounting processes.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:6. Accounting Policies
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: Accounting policies describe rules for generation, transport and
../data/rfc/rfc3334.txt: storage of accounting data. They can be exchanged between AAA
../data/rfc/rfc3334.txt- instances at the user or provider premises. They provide a
../data/rfc/rfc3334.txt- standardized representation of configuration information that can be
../data/rfc/rfc3334.txt- converted into the appropriate settings for different elements of the
../data/rfc/rfc3334.txt: accounting infrastructures (e.g. different meters).
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: As shown in Figure 2, accounting policies configure the accounting
../data/rfc/rfc3334.txt- process. Policies for the configuration of the metering and
../data/rfc/rfc3334.txt: collection process can be derived from accounting policies.
../data/rfc/rfc3334.txt: Accounting policies are not used to configure the charging or billing
../data/rfc/rfc3334.txt: process. Accounting policies reside in the AAA server (local
../data/rfc/rfc3334.txt- policies) or are received from other AAA servers (extra-domain
../data/rfc/rfc3334.txt- policies) or customers/users. Two different models of obtaining
../data/rfc/rfc3334.txt: accounting policies can be differentiated: push and pull model.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- Push Model
../data/rfc/rfc3334.txt: In the push model, accounting policies are pushed from another AAA
../data/rfc/rfc3334.txt- server or customer/user in order to establish the policies in the
../data/rfc/rfc3334.txt: local accounting infrastructure. The acceptance and use of pushed
../data/rfc/rfc3334.txt- policies requires special security considerations. The evaluation of
../data/rfc/rfc3334.txt- the policy should not take place without an appropriate security
../data/rfc/rfc3334.txt- check of the policy in advance. Also, the evaluation of the
../data/rfc/rfc3334.txt- condition can lead to unwanted actions in the AAA server if the
../data/rfc/rfc3334.txt- condition contains critical data either intentionally (to attack the
--
../data/rfc/rfc3334.txt- the condition, has to be checked for potential security hazards
../data/rfc/rfc3334.txt- before it is evaluated.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- Pull Model
../data/rfc/rfc3334.txt- In the pull model, the AAA server requests the policy from a remote
../data/rfc/rfc3334.txt: AAA server or customer/user by sending an accounting policy request.
../data/rfc/rfc3334.txt: The remote AAA server sends an accounting policy reply as an answer
../data/rfc/rfc3334.txt- that contains the appropriate policy.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 14]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: Accounting policies are enforced by the network elements that are
../data/rfc/rfc3334.txt- configured in accordance with the policies. They influence the
../data/rfc/rfc3334.txt: following settings in the accounting architecture:
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- - meter configuration
../data/rfc/rfc3334.txt- - data collection and aggregation
../data/rfc/rfc3334.txt: - accounting record distribution and storage
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:6.1 Accounting Policy Condition
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: An accounting policy consists of one or more rules, each having a
../data/rfc/rfc3334.txt- condition part and an action part. The condition part expresses
../data/rfc/rfc3334.txt- under which condition the policy should be enforced. The following
../data/rfc/rfc3334.txt- attributes are examples for variables in a policy condition
../data/rfc/rfc3334.txt- statement.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- - customer/user ID
../data/rfc/rfc3334.txt- The customer/user ID identifies the customer or user of the service.
../data/rfc/rfc3334.txt- It can be used in a policy condition in order to select a customer or
../data/rfc/rfc3334.txt: user specific accounting configuration (as policy action). For
../data/rfc/rfc3334.txt: example, it can be user-dependent whether accounting indications are
../data/rfc/rfc3334.txt- sent to the user or not.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- - IP address
../data/rfc/rfc3334.txt- IP addresses specify the devices or networks from which the service
../data/rfc/rfc3334.txt- usage takes place. The address of specific hosts or subnets can be
../data/rfc/rfc3334.txt: used to select accounting strategies specific to the customer or a
../data/rfc/rfc3334.txt- user group associated with this address (e.g. all customers of an
../data/rfc/rfc3334.txt- ISP, all public terminals etc.).
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- - time of day
../data/rfc/rfc3334.txt- The time of day can be used, for instance, to configure the level of
../data/rfc/rfc3334.txt: detail for the accounting record, the report interval and the
../data/rfc/rfc3334.txt- destination.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- - service class
../data/rfc/rfc3334.txt- Service classes are defined by the provider. They describe different
../data/rfc/rfc3334.txt- levels or different kinds of services that are offered by the
../data/rfc/rfc3334.txt- provider and are usually defined based on a business model.
../data/rfc/rfc3334.txt- Customers/users select a service class. This selected class can be
../data/rfc/rfc3334.txt: used in accounting policies to define appropriate accounting settings
../data/rfc/rfc3334.txt- per class. With this it is possible, for instance, to provide more
../data/rfc/rfc3334.txt: detailed accounting records for higher prioritized services than for
../data/rfc/rfc3334.txt- standard services.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 15]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: - accounting type
../data/rfc/rfc3334.txt: Accounting types combine multiple accounting settings under one
../data/rfc/rfc3334.txt: keyword. Like service classes, the offered accounting types are
../data/rfc/rfc3334.txt- defined by the provider in accordance with the business model. With
../data/rfc/rfc3334.txt: this, providers can offer, for instance, different accounting types
../data/rfc/rfc3334.txt- for one service and allow the customer/user to select one. The
../data/rfc/rfc3334.txt- combination of settings under one keyword simplifies the selection
../data/rfc/rfc3334.txt: for users. An example is the combination of high granular accounting
../data/rfc/rfc3334.txt- records with short report intervals under a keyword (e.g.
../data/rfc/rfc3334.txt: "comprehensive accounting"), or less frequent generation of less
../data/rfc/rfc3334.txt: detailed records accessed by another keyword ("standard accounting").
../data/rfc/rfc3334.txt: The definition of accounting types can also help in inter-domain
../data/rfc/rfc3334.txt: scenarios if providers agree on accounting types.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:6.2 Accounting Policy Action
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- The action part defines the action that takes place if the condition
../data/rfc/rfc3334.txt: is true. The action for an accounting policy is usually the
../data/rfc/rfc3334.txt: configuration of the accounting infrastructure. This can already
../data/rfc/rfc3334.txt- include settings for meters and collection entities. The following
../data/rfc/rfc3334.txt: list gives examples for parameters of the accounting infrastructure
../data/rfc/rfc3334.txt: that can be configured by an accounting policy action:
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: - accounting record type/structure
../data/rfc/rfc3334.txt: The required accounting data depends on the charging scheme.
../data/rfc/rfc3334.txt: Therefore, different accounting records should be supported. There
../data/rfc/rfc3334.txt- are two possibilities: Either different record types are defined, or
../data/rfc/rfc3334.txt- a flexible record is used that consists of a variable set of
../data/rfc/rfc3334.txt: accounting attributes. Accounting policies can be used to
../data/rfc/rfc3334.txt: communicate to neighbor providers which kind of accounting record is
../data/rfc/rfc3334.txt- needed to provide appropriate data for the charging scheme. The
../data/rfc/rfc3334.txt: specification of the required accounting attributes can influence the
../data/rfc/rfc3334.txt: settings of different components of the accounting architecture (e.g.
../data/rfc/rfc3334.txt: which attributes have to be measured). An overview of accounting
../data/rfc/rfc3334.txt- attributes and records can be found in [RFC2924].
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: - accounting record destination
../data/rfc/rfc3334.txt: The accounting record destination describes to which entities
../data/rfc/rfc3334.txt: accounting records are sent. The accounting record destination can
../data/rfc/rfc3334.txt- be a charging entity, a neighbor provider, a user entity or a
../data/rfc/rfc3334.txt- specific database. In these cases, authentication and authorization
../data/rfc/rfc3334.txt- mechanisms have to be applied in order to ensure that unauthorized
../data/rfc/rfc3334.txt- entities cannot get access to confidential data.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- - report interval
../data/rfc/rfc3334.txt: The report interval specifies in what time intervals accounting
../data/rfc/rfc3334.txt- records are generated and sent. This influences the configuration of
../data/rfc/rfc3334.txt: meters and collectors in the accounting architecture.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 16]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- - storage time
../data/rfc/rfc3334.txt: If the accounting record destination is a database or a log file, the
../data/rfc/rfc3334.txt: storage time specifies how long the accounting records have to be
../data/rfc/rfc3334.txt- stored.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- - access list
../data/rfc/rfc3334.txt- The access list specifies who has the permissions to read the stored
../data/rfc/rfc3334.txt: accounting records.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- - flow granularity
../data/rfc/rfc3334.txt- The flow granularity determines how fine grained (in coverage) the
../data/rfc/rfc3334.txt- flows in the network are measured. The granularity usually is
../data/rfc/rfc3334.txt- configured by installing specific classification rules in the meter.
--
../data/rfc/rfc3334.txt- used to configure sampling schemes.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-6.3 Example for Meter Configuration
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- Note: In the following examples, the use of NeTraMet or NetFlow to
../data/rfc/rfc3334.txt: collect accounting information does not guarantee exact
../data/rfc/rfc3334.txt: accounting data, so it is not recommended for use in situations
../data/rfc/rfc3334.txt: where exact accounting data are needed.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: The following two examples show how accounting policies can be used
../data/rfc/rfc3334.txt: to configure different meters. The accounting policy is sent from
../data/rfc/rfc3334.txt- the AAA server to the ASM and there converted to the appropriate
../data/rfc/rfc3334.txt- configuration information for the used meter.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- If the meter NeTraMet [RFC2123] is used, the policy is converted into
../data/rfc/rfc3334.txt- a NeTraMet ruleset that contains the relevant flows, attributes and
--
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 17]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- +------------------+
../data/rfc/rfc3334.txt- | AAA |
../data/rfc/rfc3334.txt- | |
../data/rfc/rfc3334.txt- +------------------+
../data/rfc/rfc3334.txt- | ^
../data/rfc/rfc3334.txt: Policy | | Accounting Records
../data/rfc/rfc3334.txt- V |
../data/rfc/rfc3334.txt- +------------------+
../data/rfc/rfc3334.txt- | ASM |
../data/rfc/rfc3334.txt- | |
../data/rfc/rfc3334.txt- +------------------+
../data/rfc/rfc3334.txt- | ^
../data/rfc/rfc3334.txt- | |
../data/rfc/rfc3334.txt- | config +-----------------+
../data/rfc/rfc3334.txt- | |
../data/rfc/rfc3334.txt- +-------------------------------+ |
../data/rfc/rfc3334.txt: | | Accounting | |
../data/rfc/rfc3334.txt- | V | |
../data/rfc/rfc3334.txt- | +----------------+ | |
../data/rfc/rfc3334.txt: | | Meter Manager | | | Accounting Records
../data/rfc/rfc3334.txt- | +----------------+ | |
../data/rfc/rfc3334.txt- | | | | |
../data/rfc/rfc3334.txt- | SNMP V | |
../data/rfc/rfc3334.txt- | (conf)+---------------+ | |
../data/rfc/rfc3334.txt- | | | Meter Reader |---------+
--
../data/rfc/rfc3334.txt- | | Meter |-----+ |
../data/rfc/rfc3334.txt- | +-----------+ SNMP(DATA) |
../data/rfc/rfc3334.txt- | |
../data/rfc/rfc3334.txt- +-------------------------------+
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: Figure 3: Policy based Accounting with NeTraMet
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- If the meter NetFlow [NetFlow] is used, the meter policies are
../data/rfc/rfc3334.txt- translated by the ASM into filter instructions for the flow
../data/rfc/rfc3334.txt- collector. The meter itself is static and therefore is not affected
../data/rfc/rfc3334.txt- by the configuration information.
--
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 18]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- +------------------+
../data/rfc/rfc3334.txt- | AAA |
../data/rfc/rfc3334.txt- | |
../data/rfc/rfc3334.txt- +------------------+
../data/rfc/rfc3334.txt- | ^
../data/rfc/rfc3334.txt: Policy | | Accounting Records
../data/rfc/rfc3334.txt- V |
../data/rfc/rfc3334.txt- +------------------+
../data/rfc/rfc3334.txt- | ASM |
../data/rfc/rfc3334.txt- | |
../data/rfc/rfc3334.txt- +------------------+
../data/rfc/rfc3334.txt- | ^
../data/rfc/rfc3334.txt- | |
../data/rfc/rfc3334.txt: | config | Accounting Records
../data/rfc/rfc3334.txt- | |
../data/rfc/rfc3334.txt- +-------------------------------+
../data/rfc/rfc3334.txt: | | Accounting |
../data/rfc/rfc3334.txt- | | |
../data/rfc/rfc3334.txt- | | +---------------------+ |
../data/rfc/rfc3334.txt- | | | Flow Collector | |
../data/rfc/rfc3334.txt- | | | +------------+ | |
../data/rfc/rfc3334.txt- | | | | Classifier | | |
--
../data/rfc/rfc3334.txt- | | Meter |-----+ |
../data/rfc/rfc3334.txt- | +-----------+ UDP (DATA) |
../data/rfc/rfc3334.txt- | |
../data/rfc/rfc3334.txt- +-------------------------------+
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: Figure 4: Policy based Accounting with NetFlow
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:7. Accounting Services
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: Accounting can be seen as part of the service provisioning process
../data/rfc/rfc3334.txt: (integrated accounting) or as a separate service (discrete
../data/rfc/rfc3334.txt: accounting). The different views and their impact on the accounting
../data/rfc/rfc3334.txt- architecture are described below.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:7.1 Integrated Accounting
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: In the integrated accounting model, the accounting is seen as part of
../data/rfc/rfc3334.txt: the provisioned service. That means the accounting is coupled with a
../data/rfc/rfc3334.txt: specific service. Therefore, the accounting process is tailored to
../data/rfc/rfc3334.txt: the specific service and might collect accounting information by
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 19]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- directly exploiting some service specific entities. For example,
../data/rfc/rfc3334.txt: accounting for IP telephony could use call signaling information from
../data/rfc/rfc3334.txt: a SIP server. The configuration of the accounting architecture is
../data/rfc/rfc3334.txt- done as part of the user configuration of the service equipment.
../data/rfc/rfc3334.txt: Accounting policies are defined as part of the contractual agreement.
../data/rfc/rfc3334.txt- The ASM converts the instructions from the AAA server into the
../data/rfc/rfc3334.txt: appropriate user configuration including settings for the accounting
../data/rfc/rfc3334.txt- architecture.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- +---------------------+
../data/rfc/rfc3334.txt- <---1--->| Generic AAA Server |<---1--->
../data/rfc/rfc3334.txt- | | ............
--
../data/rfc/rfc3334.txt- |
../data/rfc/rfc3334.txt- V
../data/rfc/rfc3334.txt- +-------------------------------------+
../data/rfc/rfc3334.txt- | Service |
../data/rfc/rfc3334.txt- | +-----------+ +----------------+ | ..............
../data/rfc/rfc3334.txt: | | Service |<-->| Accounting/ |<--3-->: Accounting :
../data/rfc/rfc3334.txt- | | Provision | | Metering | | : Data :
../data/rfc/rfc3334.txt- | +-----------+ +----------------+ | :............:
../data/rfc/rfc3334.txt- +-------------------------------------+
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: Figure 5: AAA Server with Integrated Accounting
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- Data about the resource consumption is sent back to the AAA server
../data/rfc/rfc3334.txt: via the ASM. The accounting process within the service converts the
../data/rfc/rfc3334.txt: metered data into accounting records which are sent to the AAA
../data/rfc/rfc3334.txt: server. For generating accounting records data conversion,
../data/rfc/rfc3334.txt- aggregation and filtering of data might be performed.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 20]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:7.2 Discrete Accounting
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: In contrast to the integrated accounting approach, accounting can
../data/rfc/rfc3334.txt- also be seen as a separate or discrete service on its own. In this
../data/rfc/rfc3334.txt: case the accounting does not have to be coupled with a specific
../data/rfc/rfc3334.txt: service. Discrete Accounting can be used for outsourcing the
../data/rfc/rfc3334.txt: accounting task. The accounting service can be provided by a general
../data/rfc/rfc3334.txt: accounting system which is able to account for different services.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: For example, a generalized meter can do accounting for web traffic,
../data/rfc/rfc3334.txt: FTP traffic and voice over IP traffic. If accounting is a separate
../data/rfc/rfc3334.txt: service, one provider can do the accounting (charging and billing)
../data/rfc/rfc3334.txt: for several other service providers. Accounting is offered just like
../data/rfc/rfc3334.txt- any other service. This means authentication and authorization might
../data/rfc/rfc3334.txt: be required prior to the accounting service provisioning.
../data/rfc/rfc3334.txt- Furthermore, it is important that the involved parties agree
../data/rfc/rfc3334.txt: beforehand how the accounting service is provided, what parameters
../data/rfc/rfc3334.txt: can be set and how disputes will be resolved. After the accounting
../data/rfc/rfc3334.txt- service has been configured, the AAA server can do the user
../data/rfc/rfc3334.txt- configuration of the service.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- +---------------------+
../data/rfc/rfc3334.txt- <---1--->| Generic AAA Server |<---1--->
--
../data/rfc/rfc3334.txt- | |
../data/rfc/rfc3334.txt- 5 5
../data/rfc/rfc3334.txt- | |
../data/rfc/rfc3334.txt- V V
../data/rfc/rfc3334.txt- +-------------+ +---------------+ ..............
../data/rfc/rfc3334.txt: | Service | | Accounting/ |<--3-->: Accounting :
../data/rfc/rfc3334.txt- | | | Metering | : Data :
../data/rfc/rfc3334.txt- +-------------+ +---------------+ :............:
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: Figure 6: AAA Server with Discrete Accounting
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 21]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: A service provider that has outsourced the accounting service has to
../data/rfc/rfc3334.txt: request this service from an accounting service provider. The
../data/rfc/rfc3334.txt: generated accounting records are sent from the accounting provider to
../data/rfc/rfc3334.txt- the service provider who may make modifications to the records before
../data/rfc/rfc3334.txt- sending them to the final destination. Having such a general
../data/rfc/rfc3334.txt: accounting service might speed up the creation of new services -
../data/rfc/rfc3334.txt- especially specialized content services - in the Internet. This
../data/rfc/rfc3334.txt: separation is also beneficial to support special accounting services
../data/rfc/rfc3334.txt: (e.g. sending accounting indications to users) that are not directly
../data/rfc/rfc3334.txt- coupled to a network service. Furthermore, this separation is useful
../data/rfc/rfc3334.txt: if the same set of accounting strategies can be applied to different
../data/rfc/rfc3334.txt- services (e.g. different tariffs which can be used for a set of
../data/rfc/rfc3334.txt- services).
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- Another option is to outsource only the metering service. The meter
../data/rfc/rfc3334.txt- service provider generates meter data and sends them to the service
../data/rfc/rfc3334.txt- provider who has requested them. The service provider then generates
../data/rfc/rfc3334.txt: accounting records based on the received meter data. A separate
../data/rfc/rfc3334.txt: accounting or metering service provider can be used to validate the
../data/rfc/rfc3334.txt: accounting data generated by a service provider. If the customer
../data/rfc/rfc3334.txt- does not trust a service provider, or in the case of a legal action,
../data/rfc/rfc3334.txt: a trusted accounting or metering provider is able to validate the
../data/rfc/rfc3334.txt: correctness of the accounting data generated by the service provider.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:7.3 Intra-Domain Accounting
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: In Intra-Domain accounting [RFC2975], the data about resource
../data/rfc/rfc3334.txt- consumption is collected in one administrative domain for usage in
../data/rfc/rfc3334.txt: that domain. Accounting policies are enforced locally. Since no
../data/rfc/rfc3334.txt: exchange of accounting data with other domains is required in this
../data/rfc/rfc3334.txt: scenario, accounting policies do not need to be exchanged with other
../data/rfc/rfc3334.txt- entities.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
--
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 22]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- +-------------+
../data/rfc/rfc3334.txt- | Billing |
../data/rfc/rfc3334.txt- +-------------+
--
../data/rfc/rfc3334.txt- +-------------+
../data/rfc/rfc3334.txt- | ASM |
../data/rfc/rfc3334.txt- +-------------+
../data/rfc/rfc3334.txt- ^
../data/rfc/rfc3334.txt- | ..............
../data/rfc/rfc3334.txt: +--------------+ : Accounting :
../data/rfc/rfc3334.txt- | AAA |<--->: Policies :
../data/rfc/rfc3334.txt- +--------------+ :............:
../data/rfc/rfc3334.txt- | ^
../data/rfc/rfc3334.txt- | |
../data/rfc/rfc3334.txt- V |
../data/rfc/rfc3334.txt- +--------------+
../data/rfc/rfc3334.txt- | ASM |
../data/rfc/rfc3334.txt- +--------------+
../data/rfc/rfc3334.txt- | ^
../data/rfc/rfc3334.txt: config | | Accounting Records
../data/rfc/rfc3334.txt- V |
../data/rfc/rfc3334.txt- +------------+ +-----------|----------+
../data/rfc/rfc3334.txt- | | Service usage | +--------+-------+ |
../data/rfc/rfc3334.txt: | End System |-------------->| | Accounting | |
../data/rfc/rfc3334.txt- | | | +----------------+ |
../data/rfc/rfc3334.txt- +------------+ | |
../data/rfc/rfc3334.txt- | Service |
../data/rfc/rfc3334.txt- +----------------------+
../data/rfc/rfc3334.txt- User Provider
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: Figure 7: Intra-Domain Accounting
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:7.4 Inter-Domain Accounting
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: For Inter-Domain Accounting, at least two administratively separated
../data/rfc/rfc3334.txt: networks are involved in the accounting process. These can be a
../data/rfc/rfc3334.txt- Home- and a Foreign-Provider in a Roaming/Mobile IP Scenario
../data/rfc/rfc3334.txt- [RFC2002] or a chain of providers if service provisioning involves
../data/rfc/rfc3334.txt- data transfer and/or services from different domains. In these
../data/rfc/rfc3334.txt: scenarios, the exchange of accounting policies between providers is
../data/rfc/rfc3334.txt: necessary if accounting tasks are delegated to one provider or shared
../data/rfc/rfc3334.txt: among multiple providers. The exchange of accounting policies is
../data/rfc/rfc3334.txt- done by the AAA servers as shown in the figure below.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 23]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- | +-----------+
../data/rfc/rfc3334.txt- | | Billing |
../data/rfc/rfc3334.txt- | +-----------+
--
../data/rfc/rfc3334.txt- | | |
../data/rfc/rfc3334.txt- | | Acct. Records |
../data/rfc/rfc3334.txt- Service V | |
../data/rfc/rfc3334.txt- +------------+ usage +-----------|----------+ |
../data/rfc/rfc3334.txt- | | | +--------+-------+ | |
../data/rfc/rfc3334.txt: | End System |------>| | Accounting | | |
../data/rfc/rfc3334.txt- | | | +----------------+ | |
../data/rfc/rfc3334.txt- +------------+ | | |
../data/rfc/rfc3334.txt- | Service | |
../data/rfc/rfc3334.txt- +----------------------+ |
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- User Foreign-Provider Home-Provider
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: Figure 8: Inter-Domain Accounting (Roaming Example)
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- In this example, the foreign provider takes over the collection of
../data/rfc/rfc3334.txt: accounting data. The home provider is responsible for applying a
../data/rfc/rfc3334.txt- charging scheme and sending the bill. Therefore, the home provider
../data/rfc/rfc3334.txt: needs accounting data from the foreign provider. In order to
../data/rfc/rfc3334.txt: instruct the foreign provider about the desired accounting record
../data/rfc/rfc3334.txt: type and report frequency, the home AAA server sends an accounting
../data/rfc/rfc3334.txt- policy indication to the foreign AAA server. The indication contains
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 24]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: the accounting policy. Instead of sending an indication, the
../data/rfc/rfc3334.txt: accounting policies could also be piggy backed onto an authorization
../data/rfc/rfc3334.txt- reply. If the foreign AAA server is able to configure devices in a
../data/rfc/rfc3334.txt- way to enforce the desired policy (e.g. the meters are capable of
../data/rfc/rfc3334.txt: metering the requested attributes) the accounting policy indication
../data/rfc/rfc3334.txt- is acknowledged. In case the requested policy cannot be enforced,
../data/rfc/rfc3334.txt: the accounting service is denied. Reasons to deny the enforcement of
../data/rfc/rfc3334.txt: a specific accounting policy could be, e.g. because the meter is not
../data/rfc/rfc3334.txt- capable of measuring the requested attributes or the frequency of
../data/rfc/rfc3334.txt- records cannot be provided, or the home provider is not authorized to
../data/rfc/rfc3334.txt- get the requested detailed data. In this case procedures would be
../data/rfc/rfc3334.txt- useful to negotiate the smallest common denominator for the involved
../data/rfc/rfc3334.txt: AAA servers regarding the provisioning of accounting data.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:8. Accounting with different Authorization Models
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- The AAA authorization framework [RFC2904] introduces different
../data/rfc/rfc3334.txt- message sequences for authorization. The integration of configurable
../data/rfc/rfc3334.txt: accounting services for the message sequences can be done as
../data/rfc/rfc3334.txt- described in the following sections.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-8.1 Agent Sequence
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: The appropriate accounting policy for the authorized service is
../data/rfc/rfc3334.txt- either stored together with the authorization policy or in a separate
../data/rfc/rfc3334.txt: repository. The configuration of the accounting infrastructure can
../data/rfc/rfc3334.txt- be done together with the user configuration of the service equipment
../data/rfc/rfc3334.txt- (messages 2 and 3 in Figure 9). User-specific configuration of the
../data/rfc/rfc3334.txt: service equipment and the accounting infrastructure configuration
../data/rfc/rfc3334.txt- might involve the transfer of configuration data to multiple entities
../data/rfc/rfc3334.txt- in the network (e.g. to different routers for setting up QoS
../data/rfc/rfc3334.txt: provisioning or to dedicated accounting meters).
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
--
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 25]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- +-------------------------+
../data/rfc/rfc3334.txt- +------+ | Service Provider |
../data/rfc/rfc3334.txt- | | 1 | +-------------------+ |
--
../data/rfc/rfc3334.txt- | | | | Equipment | |
../data/rfc/rfc3334.txt- | | | +-------------------+ |
../data/rfc/rfc3334.txt- +------+ | |
../data/rfc/rfc3334.txt- +-------------------------+
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: Figure 9: Accounting and Agent Sequence
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- In the agent sequence, it is possible to allow the user to send
../data/rfc/rfc3334.txt: accounting policies (e.g. for accounting indications) together with
../data/rfc/rfc3334.txt- the authorization request to the AAA server. Figure 9 shows the
../data/rfc/rfc3334.txt: agent sequence authorization and accounting messages.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-8.2 Pull Sequence
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: The configuration of the accounting infrastructure can be done
../data/rfc/rfc3334.txt- similar to the agent sequence during the user configuration of the
../data/rfc/rfc3334.txt- service equipment. Since the pull sequence does not involve the
../data/rfc/rfc3334.txt- sending of a specific authorization request (e.g. if the service
../data/rfc/rfc3334.txt- equipment is a Network Access Server (NAS) and the authorization
../data/rfc/rfc3334.txt- sequence simply starts with the dial-in process), it would need
../data/rfc/rfc3334.txt: additional communication to support accounting policy indications
../data/rfc/rfc3334.txt- from users.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
--
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 26]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- +-------------------------+
../data/rfc/rfc3334.txt- +------+ | Service Provider |
../data/rfc/rfc3334.txt- | |AccPolInd +-------------------+ |
--
../data/rfc/rfc3334.txt- | |<------+--| Equipment | |
../data/rfc/rfc3334.txt- | | 4 | +-------------------+ |
../data/rfc/rfc3334.txt- +------+ | |
../data/rfc/rfc3334.txt- +-------------------------+
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: Figure 10: Accounting and Pull Sequence
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- This can be, for instance, achieved by a hybrid model of agent and
../data/rfc/rfc3334.txt: pull sequence where the user sends an accounting policy indication to
../data/rfc/rfc3334.txt- the AAA server in addition to the messages exchange for the pull
../data/rfc/rfc3334.txt- sequence. Figure 10 shows the pull sequence authorization and
../data/rfc/rfc3334.txt: accounting messages.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-8.3 Push Sequence
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- In the push sequence, there is no direct connection between the AAA
../data/rfc/rfc3334.txt- server and the service equipment. In this sequence there are three
../data/rfc/rfc3334.txt: possibilities for setting up the accounting infrastructure:
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: a) A standard fixed accounting procedure that has been assigned in
../data/rfc/rfc3334.txt- advance for the specific combination of authorized user and service
../data/rfc/rfc3334.txt- is used.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- b) The ticket (message 3 in Figure 11) contains information about the
../data/rfc/rfc3334.txt: accounting policies used (e.g. different tickets for the same service
../data/rfc/rfc3334.txt: with different accounting policies).
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- c) The ticket acts as a kind of digital coin and no further
../data/rfc/rfc3334.txt: accounting is needed. This model also supports the anonymous usage
../data/rfc/rfc3334.txt- of a service.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
--
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 27]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: Figure 11 shows push sequence authorization and accounting messages.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- +-------------------------+
../data/rfc/rfc3334.txt- +------+ | Service Provider |
../data/rfc/rfc3334.txt- | | 1 | +-------------------+ |
../data/rfc/rfc3334.txt- | |------+->| AAA Server | |
--
../data/rfc/rfc3334.txt- | |<-----+--| Equipment | |
../data/rfc/rfc3334.txt- | | 4 | +-------------------+ |
../data/rfc/rfc3334.txt- +------+ | |
../data/rfc/rfc3334.txt- +-------------------------+
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: Figure 11: Accounting and Push Sequence
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-8.4 Roaming
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- If the provisioning of the service and the final authentication/
../data/rfc/rfc3334.txt: authorization process is done by different organizations, accounting
../data/rfc/rfc3334.txt- is rather coupled to the service provisioning process than to the
../data/rfc/rfc3334.txt- authentication/authorization process. Since the data doesn't have to
../data/rfc/rfc3334.txt- traverse the home providers network, the home provider has no
../data/rfc/rfc3334.txt- possibility of collecting data about the resource consumption.
../data/rfc/rfc3334.txt: Therefore, accounting will usually take place in the foreign provider
../data/rfc/rfc3334.txt- domain (i.e. in the domain that does the service provisioning).
../data/rfc/rfc3334.txt- Nevertheless, in order to ensure consistency of the authentication,
../data/rfc/rfc3334.txt: authorization and accounting processes (e.g. allocation of user IDs
../data/rfc/rfc3334.txt: to accounting records) and the production of a bill, a connection
../data/rfc/rfc3334.txt: between the accounting process in the service provisioning domain and
../data/rfc/rfc3334.txt- the deciding authentication/authorization process (e.g. at the home
../data/rfc/rfc3334.txt- provider) is needed.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- A possible way of doing this is if the foreign provider gets the
../data/rfc/rfc3334.txt: accounting policies from the home provider and sets up the accounting
../data/rfc/rfc3334.txt- architecture in accordance to the given policies, the foreign
../data/rfc/rfc3334.txt: provider can generate accounting records and send them back to the
../data/rfc/rfc3334.txt- home provider. The home provider then can apply charging and can
../data/rfc/rfc3334.txt- produce a bill. An example for this is given in section 9.2. This
../data/rfc/rfc3334.txt- scenario requires a prior agreement between the involved providers
../data/rfc/rfc3334.txt- about the possible policies and parameters that are allowed to be
../data/rfc/rfc3334.txt- set.
--
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 28]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-9. Examples
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: The following examples illustrate the use of policy-based accounting.
../data/rfc/rfc3334.txt- Please note that the services used in the examples are used only for
../data/rfc/rfc3334.txt- illustration purposes and their use in reality requires different
../data/rfc/rfc3334.txt- messages and parameters.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-9.1 Printing Service Example
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- The Internet Printing Protocol (IPP) [RFC2566], and especially the
../data/rfc/rfc3334.txt- "print-by-reference" model, provides a very interesting example
../data/rfc/rfc3334.txt: scenario for accounting and the interaction between authorization and
../data/rfc/rfc3334.txt: accounting. We will describe possible solutions for the accounting
../data/rfc/rfc3334.txt: of this service and how the accounting is triggered by the
../data/rfc/rfc3334.txt- authorization. We will show how the model presented above can be
../data/rfc/rfc3334.txt- used for this example.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- IPP "print-by-reference" allows a user to request a print service to
../data/rfc/rfc3334.txt- print a particular file. The file to be printed is not on the client
../data/rfc/rfc3334.txt- system but rather on a public server. That is, the clients print
../data/rfc/rfc3334.txt- request can contain a reference, or pointer, to the document instead
../data/rfc/rfc3334.txt- of the actual document itself. The print service must then read the
../data/rfc/rfc3334.txt- file to a file server (used for spooling) prior to the printing.
../data/rfc/rfc3334.txt- There are two possible setups: The file and print server either
../data/rfc/rfc3334.txt: belong to a single organization (Intra-Domain Accounting) or to two
../data/rfc/rfc3334.txt: different organizations (Inter-Domain Accounting). In the first
../data/rfc/rfc3334.txt- case, the user must be authorized by a single service provider for
../data/rfc/rfc3334.txt- service usage. In the second case, two different possibilities for
../data/rfc/rfc3334.txt- establishing a trust relationships between the involved entities have
../data/rfc/rfc3334.txt- to be distinguished [RFC2905].
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:9.1.1 Intra-Domain Accounting
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- In the case of a single organization, the file and print service is
../data/rfc/rfc3334.txt- provided by a single service provider. The service subscriber and
../data/rfc/rfc3334.txt- user role are either one entity (e.g. private home user) or different
../data/rfc/rfc3334.txt- entities (e.g. company as subscriber, employee as user). For data
../data/rfc/rfc3334.txt- transport via the underlying network, the transportation service of a
../data/rfc/rfc3334.txt- network provider is used. In this case, the AAA server of the
../data/rfc/rfc3334.txt- provider controls the access to the file and the print server. This
../data/rfc/rfc3334.txt: means the AAA server enforces the accounting policies and collects
../data/rfc/rfc3334.txt: accounting data for both servers.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
--
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 29]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:9.1.2 Inter-Domain Accounting
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- If two different organizations are involved there are two
../data/rfc/rfc3334.txt- possibilities for trust relationships as shown in [RFC2905]:
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- 1. The user has an agreement with the print server; the print
--
../data/rfc/rfc3334.txt- 2. The user has agreements with both print and file server.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- In case 1, the user is first authorized by the print service and the
../data/rfc/rfc3334.txt- request is forwarded to the file server. The file server authorizes
../data/rfc/rfc3334.txt- the print server and determines if the printer is allowed to access
../data/rfc/rfc3334.txt: the file. In this case which is shown in Figure 12, the accounting
../data/rfc/rfc3334.txt- policies from the user arrive at the print service AAA server.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- USER DOMAIN PRINT SERVICE DOMAIN FILE SERVICE DOMAIN
../data/rfc/rfc3334.txt- | |
../data/rfc/rfc3334.txt- +------+ | |
--
../data/rfc/rfc3334.txt- | | | | and Printer | | | |
../data/rfc/rfc3334.txt- +------+ | +--------------------+ | +-------------------+
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- 1: AccPolInd, 2: AccPolConf
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: Figure 12: Inter-Domain Accounting and Printing Service
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- The print service AAA server has to decide which policies can be
../data/rfc/rfc3334.txt- enforced locally and which must be passed further to the file service
../data/rfc/rfc3334.txt: AAA server. The print service can add additional accounting
../data/rfc/rfc3334.txt- policies. In case the file server does not support the desired
../data/rfc/rfc3334.txt: accounting policies, the print server must notify the user's AAA
../data/rfc/rfc3334.txt- server and some policy conflict resolution must occur. After the
../data/rfc/rfc3334.txt- file server has transferred the file to the print service, it
../data/rfc/rfc3334.txt: generates an accounting record according to the accounting policy and
../data/rfc/rfc3334.txt- passes it to the print service. The print service generates the
../data/rfc/rfc3334.txt: final accounting record for the service session based on its own and
../data/rfc/rfc3334.txt- the file service data after finishing printing. This record will be
../data/rfc/rfc3334.txt- used for the later billing process. Additionally, the print server
../data/rfc/rfc3334.txt- can send the final record to the user's AAA server. There it can be
../data/rfc/rfc3334.txt- used for later authorization decisions based on used resources, i.e.
../data/rfc/rfc3334.txt- if the customer is a company and the user is an employee.
--
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 30]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- In case 2, the customer AAA server has an agreement with file and
../data/rfc/rfc3334.txt: print server. In this case, the user's AAA server sends accounting
../data/rfc/rfc3334.txt- policies to the file and the print server. After finishing the
../data/rfc/rfc3334.txt: service, both servers generate accounting records for the delivered
../data/rfc/rfc3334.txt- services which are used for later billing. As in the former case,
../data/rfc/rfc3334.txt: the accounting data can be sent to the user's AAA server for use in
../data/rfc/rfc3334.txt- later authorization decisions. The user's AAA server can tie both
../data/rfc/rfc3334.txt: accounting records together and assign them to the user using audited
../data/rfc/rfc3334.txt: session information (authorization and accounting messages for a
../data/rfc/rfc3334.txt- particular session could be coupled via a session ID) and policies
../data/rfc/rfc3334.txt- that define which activities a certain session is composed of.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:9.1.3 User Accounting Indication
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- For the printing service, there are a number of possible options for
../data/rfc/rfc3334.txt: sending accounting indications to the user. Accounting indications
../data/rfc/rfc3334.txt- give the user an indication of how much resources have been used
../data/rfc/rfc3334.txt: until the time of the indication. A user can receive accounting
../data/rfc/rfc3334.txt: indications or not depending on the accounting policy for the user.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- For Internet printing with the "print-by-reference" model, such
../data/rfc/rfc3334.txt- indications would be very helpful for the user. Since the file is
../data/rfc/rfc3334.txt- not on the clients site, the user might not have information on the
../data/rfc/rfc3334.txt- file size or the number of pages that will be printed. This means
../data/rfc/rfc3334.txt- the user has no idea of the costs of the service usage. If user and
../data/rfc/rfc3334.txt: subscriber are a single entity, accounting indications would help
../data/rfc/rfc3334.txt- users to avoid exceeding their spending limit. Additionally,
../data/rfc/rfc3334.txt: accounting indications give the user a hint as to which resource
../data/rfc/rfc3334.txt- usage has caused the charges. This can be compared to an itemized
../data/rfc/rfc3334.txt- telephony bill where not only the monetary sum per month is printed
../data/rfc/rfc3334.txt- but, in addition, information for every call (start time, duration,
../data/rfc/rfc3334.txt- distance etc.) and its corresponding charge.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-9.2 Mobile/Roaming Example
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- In this section, the "Dial-in with Roaming" example from the
../data/rfc/rfc3334.txt- authorization examples [RFC2905], [RFC2002] is used to show how
../data/rfc/rfc3334.txt: accounting functions could interact with authorization functions.
../data/rfc/rfc3334.txt: The accounting modules (e.g. collectors and meters) are seen here as
../data/rfc/rfc3334.txt- part of the service equipment which is, in this example, located at
../data/rfc/rfc3334.txt: the visited ISP premises. The basic configuration of the accounting
../data/rfc/rfc3334.txt- modules is probably done by the visited ISP itself, but the visited
../data/rfc/rfc3334.txt- ISP can allow the home ISP to influence certain parameters (like
../data/rfc/rfc3334.txt: report interval or accounting record format). This is useful if the
../data/rfc/rfc3334.txt- home provider generates the invoice and therefore needs appropriate
../data/rfc/rfc3334.txt: accounting records to calculate the prices.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 31]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- User | Visited ISP | Home ISP
../data/rfc/rfc3334.txt- | |
../data/rfc/rfc3334.txt- | | +-----------+ ..........
--
../data/rfc/rfc3334.txt- | | 6 8 |
../data/rfc/rfc3334.txt- | | | | |
../data/rfc/rfc3334.txt- | +------------+------+-------+ |
../data/rfc/rfc3334.txt- 7 | | Service | | | |
../data/rfc/rfc3334.txt- <--------| Equipment | +----------+| |
../data/rfc/rfc3334.txt: 1 | | |->|Accounting|| |
../data/rfc/rfc3334.txt- -------->| | +----------+| |
../data/rfc/rfc3334.txt- | | config | | | |
../data/rfc/rfc3334.txt- | | | +---------+ | |
../data/rfc/rfc3334.txt- | | +->| Meters | | |
../data/rfc/rfc3334.txt- | | +---------+ | |
--
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 32]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- The exchange of authorization data corresponds to the example in
../data/rfc/rfc3334.txt- [RFC2905]. As an additional component, we introduce an ASM between
../data/rfc/rfc3334.txt- home AAA and service equipment for the user configuration which
--
../data/rfc/rfc3334.txt- via the AAA sever of the visited ISP to the home AAA server. In step
../data/rfc/rfc3334.txt- (4), user specific service parameters are given to the visited ISP's
../data/rfc/rfc3334.txt- AAA server and are forwarded to the service equipment (5) where the
../data/rfc/rfc3334.txt- user configuration is done. The user-specific service parameters
../data/rfc/rfc3334.txt- could additionally include the desired policies for the configuration
../data/rfc/rfc3334.txt: of the accounting infrastructure of the visited ISP. An accounting
../data/rfc/rfc3334.txt: policy could be, for instance, "for user X one accounting record of
../data/rfc/rfc3334.txt: type Y has to be generated every 30 seconds". This accounting policy
../data/rfc/rfc3334.txt- is used by the visited ISP to configure his modules (e.g. metering,
../data/rfc/rfc3334.txt- data collection).
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- User-dependent service parameters are converted by the ASM into the
../data/rfc/rfc3334.txt- appropriate configuration information (6). Then the user is informed
../data/rfc/rfc3334.txt- about the completed authentication/authorization process (7). The
../data/rfc/rfc3334.txt: accounting architecture starts metering the resource usage and sends
../data/rfc/rfc3334.txt- metering records to the ASM (8). The ASM uses the metered data to
../data/rfc/rfc3334.txt: fill the required accounting records and sends them to the visited
../data/rfc/rfc3334.txt- ISP's AAA server (9). The visited ISP can either post-process the
../data/rfc/rfc3334.txt- data or directly forward them to the home ISP (10). With this data
../data/rfc/rfc3334.txt- as input, an invoice is generated by the charging and billing modules
../data/rfc/rfc3334.txt- within the home providers domain (11) by using charging policies
../data/rfc/rfc3334.txt- (tariff formulas), and then sent to the user/customer (12).
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: As an additional option, accounting records can also be offered to
../data/rfc/rfc3334.txt: the user (accounting indication) as a special service. For this
../data/rfc/rfc3334.txt- special service a separate authorization is required.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-9.3 Diffserv Example
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: This example explains how integrated accounting is configured via
../data/rfc/rfc3334.txt- policies for a Diffserv service [RFC2475] based on bandwidth brokers
../data/rfc/rfc3334.txt- [I2-BB]. The service is the transport of packets with a higher
../data/rfc/rfc3334.txt: priority and the service includes accounting and QoS auditing.
../data/rfc/rfc3334.txt- Figure 14 shows the service setup. The user issues a Service Request
../data/rfc/rfc3334.txt- (SR) for a Diffserv service to the AAA server. The request contains
../data/rfc/rfc3334.txt- a user ID and the parameter for the desired service class.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- User->AAA: user-x@nw-a, service=diffserv, class=gold,
--
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 33]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- In this example, user-x is located at network A (nw-a) and requests a
../data/rfc/rfc3334.txt- gold class service for all flows from this network to the destination
../data/rfc/rfc3334.txt- network B (nw-b). After authentication and authorization has been
--
../data/rfc/rfc3334.txt- dest=nw-b
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- The ASM takes over the task of translating the application specific
../data/rfc/rfc3334.txt- information into appropriate user configuration information for the
../data/rfc/rfc3334.txt- service equipment. For the given Diffserv example, the service
../data/rfc/rfc3334.txt: equipment consists of three components: accounting equipment, the QoS
../data/rfc/rfc3334.txt- auditing equipment and the bandwidth broker architecture. The ASM
../data/rfc/rfc3334.txt- has to address all three components to set up the requested service
../data/rfc/rfc3334.txt- for the user. The translation of the ASI into configuration
../data/rfc/rfc3334.txt- information for the components can be done by evaluating service
../data/rfc/rfc3334.txt- provisioning policies. For example, the ASM could have the following
../data/rfc/rfc3334.txt- service provisioning policy:
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- if class==gold {
../data/rfc/rfc3334.txt- set bw-request.class = gold
../data/rfc/rfc3334.txt: set accounting.type = comprehensive
../data/rfc/rfc3334.txt- set qos-audit.metric = one-way-delay
../data/rfc/rfc3334.txt- ...
../data/rfc/rfc3334.txt- }
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- This results in sending a bandwidth request to the BB which asks for
../data/rfc/rfc3334.txt- a gold service with the given parameters. Furthermore, the ASM
../data/rfc/rfc3334.txt: issues a request to the accounting equipment for comprehensive
../data/rfc/rfc3334.txt: accounting and a request to the QoS auditing equipment for a one-
../data/rfc/rfc3334.txt- way-delay measurement between the given networks.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- ASM->BB: BW-request(gold, src=nw-a, dest=nw-b, amount=2Mbit)
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- ASM->Acct: Acct-request(comprehensive, src=nw-a)
--
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- The bandwidth broker then sets up the Diffserv infrastructure to
../data/rfc/rfc3334.txt- provide the prioritized forwarding according to the definition of a
../data/rfc/rfc3334.txt- gold class. This is done in accordance with the actual bandwidth
../data/rfc/rfc3334.txt- broker's architecture and is not further considered here. For the
../data/rfc/rfc3334.txt: Accounting Configuration and the QoS Audit Control, local
../data/rfc/rfc3334.txt- configuration policies exist for setting up the service.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 34]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: Accounting-Policy:
../data/rfc/rfc3334.txt- if type==comprehensive {
../data/rfc/rfc3334.txt- set meter-location = access-point(nw-a)
../data/rfc/rfc3334.txt- set record type =detailed
../data/rfc/rfc3334.txt- set report interval = 120 s
../data/rfc/rfc3334.txt- set report target = 193.175.12.8
--
../data/rfc/rfc3334.txt- set timestampsize = 48 bit
../data/rfc/rfc3334.txt- set ingress-meter-location = access-point(nw-a)
../data/rfc/rfc3334.txt- set egress-meter-location = access-point(nw-b)
../data/rfc/rfc3334.txt- }
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: In this case, the local accounting policy sets the meter location to
../data/rfc/rfc3334.txt- the network access point of network A. It states that for
../data/rfc/rfc3334.txt: comprehensive accounting, a detailed record type is required with a
../data/rfc/rfc3334.txt- report interval of 120 s. The resulting records have to be sent to
../data/rfc/rfc3334.txt- the given report target. The QoS measurement policy sets the
../data/rfc/rfc3334.txt- measurement method to passive measurement. It sets the size used for
../data/rfc/rfc3334.txt- timestamp representation to 48 bits. As meter locations, the meters
../data/rfc/rfc3334.txt- at the access points of network A and network B are used.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- After evaluating these policies, the instructions for the meter
../data/rfc/rfc3334.txt- configuration are passed down to the measurement infrastructure. In
../data/rfc/rfc3334.txt: our example, the accounting configuration instructs the meter at the
../data/rfc/rfc3334.txt- first measurement point (MP1) to add a new rule with the given flow
../data/rfc/rfc3334.txt- attributes and settings for storage and reporting of results.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
--
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 35]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- Acct->MI: MP1: add rule dscp=23, src=a.a.a/24, dest=b.b.b.b/24
../data/rfc/rfc3334.txt- save volume
../data/rfc/rfc3334.txt- set report interval = 120 s
--
../data/rfc/rfc3334.txt- | | |
../data/rfc/rfc3334.txt- -----|----------------------------------------|--------------|-----
../data/rfc/rfc3334.txt- | Service Equipment | |
../data/rfc/rfc3334.txt- V V V
../data/rfc/rfc3334.txt- +---------------+ .............. +-----------+ +-----------+
../data/rfc/rfc3334.txt: | Accounting |<-->: Local :<-->| QoS | | Bandwidth |
../data/rfc/rfc3334.txt- | | : Policies : | Auditing | | Broker |
../data/rfc/rfc3334.txt- +---------------+ :............: +-----------+ +-----------+
../data/rfc/rfc3334.txt- | |
../data/rfc/rfc3334.txt- | Meter Instructions | Measurement Setup
../data/rfc/rfc3334.txt- V V
--
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 36]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:9.4 User Accounting Indication Example
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: This example explains how discrete accounting can be used to provide
../data/rfc/rfc3334.txt: accounting indications for the user. Accounting indications are sent
../data/rfc/rfc3334.txt- to the user in order to inform the user about current resource
../data/rfc/rfc3334.txt: consumption. The accounting indication is a special accounting
../data/rfc/rfc3334.txt: service that can be provided in addition to the standard accounting
../data/rfc/rfc3334.txt- performed by the provider. Like for any other service, an
../data/rfc/rfc3334.txt: authorization should take place before the accounting indication
../data/rfc/rfc3334.txt: service provisioning. Therefore, the accounting here is seen as a
../data/rfc/rfc3334.txt: separate service. That means the accounting service is independent
../data/rfc/rfc3334.txt- of the main service and therefore can be applied to different
../data/rfc/rfc3334.txt- services. It might be used as an addition to an integrated
../data/rfc/rfc3334.txt: accounting that is part of the service. The authorization process
../data/rfc/rfc3334.txt: for the accounting service is out of the scope of this document and
../data/rfc/rfc3334.txt- therefore is not further explained here.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- Figure 15 illustrates the configuration message sequence for setting
../data/rfc/rfc3334.txt: up the accounting service. First, the user sends an Accounting
../data/rfc/rfc3334.txt- Service Request (ASR) to the AAA server which includes desired
../data/rfc/rfc3334.txt: parameters for the provisioning of the accounting service (e.g.
../data/rfc/rfc3334.txt- report interval).
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: user->AAA: user-x@nw-a, service= accounting indications,
../data/rfc/rfc3334.txt- report interval= 60 s
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: The AAA server passes the ASI to the ASM of the accounting service
../data/rfc/rfc3334.txt- after the user has been authenticated and authorized for the service
../data/rfc/rfc3334.txt- usage.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: AAA->ASM: user-x@nw-a, service=accounting indications,
../data/rfc/rfc3334.txt- report interval= 60 s
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
--
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 37]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: The ASM generates an accounting policy based on the ASI and passes
../data/rfc/rfc3334.txt: this policy to the Accounting Configuration.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- ASM->Acct: If src=a.a.a.x {
../data/rfc/rfc3334.txt- acc-indication = on
../data/rfc/rfc3334.txt- report interval = 60s
../data/rfc/rfc3334.txt- report target= a.a.a.x
--
../data/rfc/rfc3334.txt- +-------+
../data/rfc/rfc3334.txt- | ASM |
../data/rfc/rfc3334.txt- +-------+
../data/rfc/rfc3334.txt- |
../data/rfc/rfc3334.txt- -------------------------|---------------------------
../data/rfc/rfc3334.txt: Service Equipment | Accounting Policy
../data/rfc/rfc3334.txt- V
../data/rfc/rfc3334.txt- +-----------------+ ..............
../data/rfc/rfc3334.txt: | Accounting |<---->: Local Acct :
../data/rfc/rfc3334.txt- | | : Policies :
../data/rfc/rfc3334.txt- +-----------------+ :............:
../data/rfc/rfc3334.txt- |
../data/rfc/rfc3334.txt- | Meter Instructions
../data/rfc/rfc3334.txt- V
../data/rfc/rfc3334.txt- +-----------------+
../data/rfc/rfc3334.txt- | Measurement |
../data/rfc/rfc3334.txt- | Infrastructure |
../data/rfc/rfc3334.txt- +-----------------+
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: Figure 15: Accounting Indication Configuration
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: The Accounting Configuration generates meter instructions according
../data/rfc/rfc3334.txt: to the accounting policies from the ASM and local accounting policies
../data/rfc/rfc3334.txt- and passes them to the measurement infrastructure.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- local Acct-Policy: if acc-indication {
../data/rfc/rfc3334.txt- record type = compact
../data/rfc/rfc3334.txt- }
--
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 38]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-10. Security Considerations
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: Accounting services provide the basis for billing. Therefore, the
../data/rfc/rfc3334.txt- incentives (mainly saving money) and potential for fraud is extremely
../data/rfc/rfc3334.txt: high in the field of configuration of the accounting architecture and
../data/rfc/rfc3334.txt: the collection of accounting data. In the presented framework, two
../data/rfc/rfc3334.txt: types of data communications are required, the exchange of accounting
../data/rfc/rfc3334.txt: policies and the collection of accounting records. Both
../data/rfc/rfc3334.txt- communications introduce potential security hazards.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- The following potential security hazards can be identified:
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: - Forgery of accounting policies and accounting record information
../data/rfc/rfc3334.txt: Both accounting policies and accounting records can be the target of
../data/rfc/rfc3334.txt: forgery of information. Accounting policies contain configuration
../data/rfc/rfc3334.txt- information. Modifying this information can lead to a mal-configured
../data/rfc/rfc3334.txt: accounting and metering system which either allows data to traverse
../data/rfc/rfc3334.txt: the accounting system undetected (without being accounted for, e.g.
../data/rfc/rfc3334.txt- by changing the classification rules of a meter) or produces bogus
../data/rfc/rfc3334.txt: accounting records. Accounting records contain data about resource
../data/rfc/rfc3334.txt: consumption and provide the basis for billing. Modifying accounting
../data/rfc/rfc3334.txt- records may lead to erroneous bills. Furthermore, it is important
../data/rfc/rfc3334.txt: that policies or accounting records are not redirected or removed and
../data/rfc/rfc3334.txt- that forged policies or records are not inserted.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- - Eavesdropping
../data/rfc/rfc3334.txt: It may be required to keep accounting policies and accounting records
../data/rfc/rfc3334.txt- confidential between the involved parties.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- - Denial of Service (DoS) attacks
../data/rfc/rfc3334.txt: Both the AAA server and the accounting/metering subsystem can be the
../data/rfc/rfc3334.txt- target of denial of service attacks. A denial of service attack
../data/rfc/rfc3334.txt- against the AAA server may lead to malfunction and even breakdown of
../data/rfc/rfc3334.txt- the server. This means the server will not be able to provide proper
../data/rfc/rfc3334.txt: authentication, authorization and accounting functionality. The
../data/rfc/rfc3334.txt- service provided by the AAA server will become unavailable or
../data/rfc/rfc3334.txt- unusable. An attack to the server can be worse than an attack to the
../data/rfc/rfc3334.txt- service equipment itself, especially if multiple services use one AAA
../data/rfc/rfc3334.txt: server. An attack against the accounting/metering system will cause
../data/rfc/rfc3334.txt: loss of metering data and/or loss of accounting records.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- This leads to the following security requirements:
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: - Secrecy of accounting policies and accounting data
../data/rfc/rfc3334.txt: Unauthorized entities should not be able to read or modify accounting
../data/rfc/rfc3334.txt: policies or accounting records. This can be achieved with standard
../data/rfc/rfc3334.txt- encryption methods.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 39]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: - Authentication of accounting data and accounting policy sources
../data/rfc/rfc3334.txt- It should be ensured that the data is originated by the original
../data/rfc/rfc3334.txt- source. Source-authentication can be achieved by using digital
../data/rfc/rfc3334.txt- signatures.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: - Protection of the integrity of accounting policies and records
../data/rfc/rfc3334.txt- It should be ensured that the data was not modified on the way from
../data/rfc/rfc3334.txt- sender to receiver. Data-authentication can also be achieved with
../data/rfc/rfc3334.txt- digital signatures.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: - Verify correctness of generated accounting data
../data/rfc/rfc3334.txt: It must be ensured that the accounting data generated by the service
../data/rfc/rfc3334.txt: provider is correct. A provider may generate incorrect accounting
../data/rfc/rfc3334.txt- records either deliberately (i.e. forging) or unintentionally (e.g.
../data/rfc/rfc3334.txt: faulty configuration). These incorrect accounting records probably
../data/rfc/rfc3334.txt- have the consequence of incorrect bills. Customers can verify the
../data/rfc/rfc3334.txt: correctness of the accounting data through their measurements and/or
../data/rfc/rfc3334.txt- through data collected by a trusted third party. A trusted third
../data/rfc/rfc3334.txt: party can be an independent accounting service provider as described
../data/rfc/rfc3334.txt- in section 7.2 or a more general entity providing an auditing
../data/rfc/rfc3334.txt- service.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- - Prevention and protection against Denial of Service attacks
../data/rfc/rfc3334.txt- The AAA protocol and all building blocks should be designed and
--
../data/rfc/rfc3334.txt- add a component to the meter system that is able to detect suspicious
../data/rfc/rfc3334.txt- traffic patterns. Upon detection, further actions can be taken
../data/rfc/rfc3334.txt- according to a pre-defined policy.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- The prevention of these hazards has to be considered for the
../data/rfc/rfc3334.txt: protocols used for accounting policy exchange and the transportation
../data/rfc/rfc3334.txt: of accounting records. Since the security requirements for
../data/rfc/rfc3334.txt- authentication, transmission level security, data object
../data/rfc/rfc3334.txt- confidentiality and integrity are addressed in the criteria for AAA
../data/rfc/rfc3334.txt- protocol evaluation [RFC2989], we assume that the future AAA
../data/rfc/rfc3334.txt: protocol(s) will be suited for secure accounting record transfer and
../data/rfc/rfc3334.txt: probably also for secure accounting policy transport. Furthermore,
../data/rfc/rfc3334.txt- we assume that existing or upcoming solutions for secure
../data/rfc/rfc3334.txt- transportation and enforcement of policies can be used. Real
../data/rfc/rfc3334.txt- prevention of DoS attacks is quite difficult. A selective dropping
../data/rfc/rfc3334.txt- of the attackers packets is impossible if the malicious packets
../data/rfc/rfc3334.txt- cannot be separated from the valid customer traffic. Dropping of all
--
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 40]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-11. References
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- [I2-BB] Internet2-QBone Bandwidth Broker,
--
../data/rfc/rfc3334.txt- [RFC2905] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
../data/rfc/rfc3334.txt- Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and
../data/rfc/rfc3334.txt- D. Spence, "AAA Authorization Application Examples", RFC
../data/rfc/rfc3334.txt- 2905, August 2000.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt: [RFC2924] Brownlee, N. and A. Blount, "Accounting Attributes and
../data/rfc/rfc3334.txt- Record Formats", RFC 2924, September 2000.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- [RFC2975] Aboba, B., Arkko, J. and D. Harrington, "Introduction to
../data/rfc/rfc3334.txt: Accounting Management", RFC 2975, October 2000.
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 41]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- [RFC2989] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann,
../data/rfc/rfc3334.txt- P., Shiino, H., Walsh, P., Zorn, G., Dommety, G.,
../data/rfc/rfc3334.txt- Perkins, C., Patil, B., Mitton, D., Manning, S.,
--
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 42]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Author's Addresses
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- Tanja Zseby
--
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Zseby, et. al. Experimental [Page 43]
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt:RFC 3334 Policy-Based Accounting October 2002
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt-Full Copyright Statement
../data/rfc/rfc3334.txt-
../data/rfc/rfc3334.txt- Copyright (C) The Internet Society (2002). All Rights Reserved.
--
../data/rfc/rfc3300.txt-WEBDAV HTTP Extensions for Distributed Authoring -- WEBDAV 2518
../data/rfc/rfc3300.txt-ATM-MIBMAN Definitions of Managed Objects for ATM Management 2515
../data/rfc/rfc3300.txt-ATM-TC-OID Definitions of Textual Conventions and 2514
../data/rfc/rfc3300.txt- OBJECT-IDENTITIES for ATM Management
../data/rfc/rfc3300.txt--------- Managed Objects for Controlling the Collection 2513
../data/rfc/rfc3300.txt: and Storage of Accounting Information for
../data/rfc/rfc3300.txt- Connection-Oriented Networks
../data/rfc/rfc3300.txt-
../data/rfc/rfc3300.txt-
../data/rfc/rfc3300.txt-
../data/rfc/rfc3300.txt-IETF Standards Track [Page 23]
../data/rfc/rfc3300.txt-
../data/rfc/rfc3300.txt-RFC 3300 Internet Standards November 2002
../data/rfc/rfc3300.txt-
../data/rfc/rfc3300.txt-
../data/rfc/rfc3300.txt:-------- Accounting Information for ATM Networks 2512
../data/rfc/rfc3300.txt-X.509-CRMF Internet X.509 Certificate Request Message Format 2511
../data/rfc/rfc3300.txt-PKICMP Internet X.509 Public Key Infrastructure Certificate 2510
../data/rfc/rfc3300.txt- Management Protocols
../data/rfc/rfc3300.txt-IPCOM-PPP IP Header Compression over PPP 2509
../data/rfc/rfc3300.txt--------- Compressing IP/UDP/RTP Headers for Low-Speed Serial 2508
--
../data/rfc/rfc3300.txt-3.7. Experimental Protocols
../data/rfc/rfc3300.txt-
../data/rfc/rfc3300.txt-Mnemonic Title RFC#
../data/rfc/rfc3300.txt-------------------------------------------------------------------------
../data/rfc/rfc3300.txt--------- Dual Stack Hosts Using "Bump-in-the-API" (BIA) 3338*
../data/rfc/rfc3300.txt:-------- Policy-Based Accounting 3334*
../data/rfc/rfc3300.txt--------- PGM Reliable Transport Protocol Specification 3208*
../data/rfc/rfc3300.txt--------- Domain Security Services using S/MIME 3183
../data/rfc/rfc3300.txt-SMX Script MIB Extensibility Protocol Version 1.1 3179
../data/rfc/rfc3300.txt--------- ISO/IEC 9798-3 Authentication SASL Mechanism 3163
../data/rfc/rfc3300.txt--------- Electronic Signature Policies 3125
--
../data/rfc/rfc4282.txt- The use of unassigned code points is prohibited.
../data/rfc/rfc4282.txt-
../data/rfc/rfc4282.txt- The mapping, normalization, and bidirectional character processing
../data/rfc/rfc4282.txt- MUST be performed by end systems that take international text as
../data/rfc/rfc4282.txt- input. In a network access setting, such systems are typically the
../data/rfc/rfc4282.txt: client and the Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc4282.txt- server. NAIs are sent over the wire in their canonical form, and
../data/rfc/rfc4282.txt- tasks such as normalization do not typically need to be performed by
../data/rfc/rfc4282.txt- nodes that just pass NAIs around or receive them from the network.
../data/rfc/rfc4282.txt- End systems MUST also perform checking for prohibited output and
../data/rfc/rfc4282.txt- unassigned code points. Other systems MAY perform such checks, when
--
../data/rfc/rfc4282.txt-
../data/rfc/rfc4282.txt- [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
../data/rfc/rfc4282.txt- "Remote Authentication Dial In User Service
../data/rfc/rfc4282.txt- (RADIUS)", RFC 2865, June 2000.
../data/rfc/rfc4282.txt-
../data/rfc/rfc4282.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June
../data/rfc/rfc4282.txt- 2000.
../data/rfc/rfc4282.txt-
../data/rfc/rfc4282.txt- [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote
../data/rfc/rfc4282.txt- Authentication Dial In User Service) Support For
../data/rfc/rfc4282.txt- Extensible Authentication Protocol (EAP)", RFC 3579,
--
../data/rfc/rfc4562.txt- different premises (i.e., accessed via different subscriber lines or
../data/rfc/rfc4562.txt- via different access networks) be forwarded via an AR, and not
../data/rfc/rfc4562.txt- bridged or switched at layer-2 (Requirement 1; see also requirement
../data/rfc/rfc4562.txt- R-40 in [TR101]). This enables the access network service provider
../data/rfc/rfc4562.txt- to use the AR(s) to perform security filtering, policing, and
../data/rfc/rfc4562.txt: accounting of all customer traffic. This implies that within the
../data/rfc/rfc4562.txt- access network, layer-2 traffic paths should not exist that
../data/rfc/rfc4562.txt- circumvent an AR (with some exceptions; see Section 3.4).
../data/rfc/rfc4562.txt-
../data/rfc/rfc4562.txt- In ATM-based access networks, the separation of individual customer
../data/rfc/rfc4562.txt- hosts' traffic is an intrinsic feature achieved by the use of ATM
--
../data/rfc/rfc4562.txt-
../data/rfc/rfc4562.txt- Access Router (AR)
../data/rfc/rfc4562.txt- The entity interconnecting the access network to the Internet or
../data/rfc/rfc4562.txt- other IP-based networks. The AR provides connectivity between
../data/rfc/rfc4562.txt- hosts on the access network at different customer premises. It is
../data/rfc/rfc4562.txt: also used to provide security filtering, policing, and accounting
../data/rfc/rfc4562.txt- of customer traffic.
../data/rfc/rfc4562.txt-
../data/rfc/rfc4562.txt- Application Server (AS)
../data/rfc/rfc4562.txt- A server, usually owned by a service provider, that attaches
../data/rfc/rfc4562.txt- directly to the aggregation network and is directly reachable at
--
../data/rfc/rfc6735.txt-
../data/rfc/rfc6735.txt-Abstract
../data/rfc/rfc6735.txt-
../data/rfc/rfc6735.txt- This document defines Attribute-Value Pair (AVP) containers for
../data/rfc/rfc6735.txt- various priority parameters for use with Diameter and the
../data/rfc/rfc6735.txt: Authentication, Authorization, and Accounting (AAA) framework. The
../data/rfc/rfc6735.txt- parameters themselves are defined in several different protocols that
../data/rfc/rfc6735.txt- operate at either the network or application layer.
../data/rfc/rfc6735.txt-
../data/rfc/rfc6735.txt-
../data/rfc/rfc6735.txt-Status of This Memo
--
../data/rfc/rfc6735.txt- +------------------------------------------------------------------+
../data/rfc/rfc6735.txt-
../data/rfc/rfc6735.txt-5.2. QoS Profile
../data/rfc/rfc6735.txt-
../data/rfc/rfc6735.txt- IANA has allocated a new value from the "QoS Profiles" subregistry of
../data/rfc/rfc6735.txt: the "Authentication, Authorization, and Accounting (AAA) Parameters"
../data/rfc/rfc6735.txt- defined in [RFC5624] for the QoS profile defined in this document.
../data/rfc/rfc6735.txt- The name of the profile is "Resource priority parameters" (1).
../data/rfc/rfc6735.txt-
../data/rfc/rfc6735.txt-6. Security Considerations
../data/rfc/rfc6735.txt-
--
../data/rfc/rfc892.txt-following set of functions which have been identified as potential
../data/rfc/rfc892.txt-transport layer functions:
../data/rfc/rfc892.txt-
../data/rfc/rfc892.txt- o provision for encryption
../data/rfc/rfc892.txt-
../data/rfc/rfc892.txt: o provision for accounting mechanisms
../data/rfc/rfc892.txt-
../data/rfc/rfc892.txt- o provision for status exchanges and monitoring of quality
../data/rfc/rfc892.txt- of service
../data/rfc/rfc892.txt-
../data/rfc/rfc892.txt- o provision for blocking
--
../data/rfc/rfc8300.txt- realize a service path. Furthermore, the NSH provides the
../data/rfc/rfc8300.txt- ability to monitor and troubleshoot a service chain, end-to-end
../data/rfc/rfc8300.txt- via service-specific Operations, Administration, and Maintenance
../data/rfc/rfc8300.txt- (OAM) messages. The NSH fields can be used by administrators
../data/rfc/rfc8300.txt- (for example, via a traffic analyzer) to verify the path
../data/rfc/rfc8300.txt: specifics (e.g., accounting, ensuring correct chaining, providing
../data/rfc/rfc8300.txt- reports, etc.) of packets being forwarded along a service path.
../data/rfc/rfc8300.txt-
../data/rfc/rfc8300.txt- 3. The NSH provides a mechanism to carry shared metadata between
../data/rfc/rfc8300.txt- participating entities and Service Functions. The semantics of
../data/rfc/rfc8300.txt- the shared metadata are communicated via a control plane (which
--
../data/rfc/rfc525.txt- 5) USER disconnect from MATHLAB.
../data/rfc/rfc525.txt-
../data/rfc/rfc525.txt- 6) User connects to and logs into OLS, and loads a file containing
../data/rfc/rfc525.txt- the user programs which produce a virtual job deck for the
../data/rfc/rfc525.txt- batch system. A sequence of questions are given to the user by
../data/rfc/rfc525.txt: these programs regarding accounting information, and the source
../data/rfc/rfc525.txt- file at MIT, and the destination file at at UCSB. The batch
../data/rfc/rfc525.txt- job gets submitted automatically, and the transfer and
../data/rfc/rfc525.txt- translation is done.
../data/rfc/rfc525.txt-
../data/rfc/rfc525.txt- 7) After the transfer is completed, the destination file may be
--
../data/rfc/rfc7930.txt-
../data/rfc/rfc7930.txt-
../data/rfc/rfc7930.txt-3.2. Discovery
../data/rfc/rfc7930.txt-
../data/rfc/rfc7930.txt- As discussed in Section 2.1, a client MAY send a Status-Server
../data/rfc/rfc7930.txt: message to discover whether an authentication or accounting server
../data/rfc/rfc7930.txt- supports this specification. The client includes a Response-Length
../data/rfc/rfc7930.txt- attribute; this signals the server to include a Response-Length
../data/rfc/rfc7930.txt- attribute indicating the maximum packet size the server can process.
../data/rfc/rfc7930.txt- In this one instance, Response-Length indicates the size of a request
../data/rfc/rfc7930.txt- that can be processed rather than a response.
../data/rfc/rfc7930.txt-
../data/rfc/rfc7930.txt-4. Protocol-Error Code
../data/rfc/rfc7930.txt-
../data/rfc/rfc7930.txt- This document defines a new RADIUS code, 52, called Protocol-Error.
../data/rfc/rfc7930.txt- This packet code may be used in response to any request packet, such
../data/rfc/rfc7930.txt: as Access-Request, Accounting-Request, CoA-Request, or Disconnect-
../data/rfc/rfc7930.txt- Request. It is a response packet sent by a server to a client. The
../data/rfc/rfc7930.txt- packet indicates to the client that the server is unable to process
../data/rfc/rfc7930.txt- the request for some reason.
../data/rfc/rfc7930.txt-
../data/rfc/rfc7930.txt- A Protocol-Error packet MUST contain an Original-Packet-Code
--
../data/rfc/rfc4857.txt- 13. IANA Considerations ...........................................30
../data/rfc/rfc4857.txt- 14. Acknowledgements ..............................................31
../data/rfc/rfc4857.txt- 15. References ....................................................32
../data/rfc/rfc4857.txt- 15.1. Normative References .....................................32
../data/rfc/rfc4857.txt- 15.2. Informative References ...................................32
../data/rfc/rfc4857.txt: Appendix A. Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc4857.txt- Interactions ..........................................33
../data/rfc/rfc4857.txt- Appendix B. Anchoring at a GFA ....................................33
../data/rfc/rfc4857.txt-
../data/rfc/rfc4857.txt-
../data/rfc/rfc4857.txt-
--
../data/rfc/rfc4857.txt- January 2007.
../data/rfc/rfc4857.txt-
../data/rfc/rfc4857.txt-15.2. Informative References
../data/rfc/rfc4857.txt-
../data/rfc/rfc4857.txt- [RFC3957] Perkins, C. and P. Calhoun, "Authentication,
../data/rfc/rfc4857.txt: Authorization, and Accounting (AAA) Registration Keys for
../data/rfc/rfc4857.txt- Mobile IPv4", RFC 3957, March 2005.
../data/rfc/rfc4857.txt-
../data/rfc/rfc4857.txt- [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and
../data/rfc/rfc4857.txt- P. McCann, "Diameter Mobile IPv4 Application", RFC 4004,
../data/rfc/rfc4857.txt- August 2005.
--
../data/rfc/rfc4857.txt-Fogelstroem, et al. Experimental [Page 32]
../data/rfc/rfc4857.txt-
../data/rfc/rfc4857.txt-RFC 4857 Mobile IPv4 Regional Registration June 2007
../data/rfc/rfc4857.txt-
../data/rfc/rfc4857.txt-
../data/rfc/rfc4857.txt:Appendix A. Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc4857.txt- Interactions
../data/rfc/rfc4857.txt-
../data/rfc/rfc4857.txt- When the mobile node has to obtain authorization by way of
../data/rfc/rfc4857.txt: Authentication, Authorization, and Accounting (AAA) infrastructure
../data/rfc/rfc4857.txt- services, the control flow implicit in the main body of this
../data/rfc/rfc4857.txt- specification is likely to be modified. Typically, the mobile node
../data/rfc/rfc4857.txt- will supply credentials for authorization by AAA as part of its
../data/rfc/rfc4857.txt- registration messages. The GFA will parse the credentials supplied
../data/rfc/rfc4857.txt- by the mobile and forward the appropriate authorization request to a
--
../data/rfc/rfc5655.txt- 1. a Version field of 10;
../data/rfc/rfc5655.txt-
../data/rfc/rfc5655.txt- 2. a Length field with the number of octets in the IPFIX
../data/rfc/rfc5655.txt- Message, generally available by subtracting 4 from the length
../data/rfc/rfc5655.txt- of the NetFlow V9 packet as returned from the transport layer
../data/rfc/rfc5655.txt: (accounting for the difference in message header lengths);
../data/rfc/rfc5655.txt-
../data/rfc/rfc5655.txt-
../data/rfc/rfc5655.txt-
../data/rfc/rfc5655.txt-
../data/rfc/rfc5655.txt-Trammell, et al. Standards Track [Page 60]
--
../data/rfc/rfc1486.txt- 2.4 Remote Printing without MIME ......................... 6
../data/rfc/rfc1486.txt- 3. The Experiment ........................................ 7
../data/rfc/rfc1486.txt- 3.1 Infrastructure ....................................... 8
../data/rfc/rfc1486.txt- 3.1.1 Zones .............................................. 8
../data/rfc/rfc1486.txt- 3.1.2 MX records ......................................... 8
../data/rfc/rfc1486.txt: 3.2 Accounting and Privacy ............................... 9
../data/rfc/rfc1486.txt- 3.3 Mailing list ......................................... 9
../data/rfc/rfc1486.txt- 3.4 Prototype Implementation ............................. 10
../data/rfc/rfc1486.txt- 4. Future Issues ......................................... 11
../data/rfc/rfc1486.txt- 5. Security Considerations ............................... 11
../data/rfc/rfc1486.txt- 6. Acknowledgements ...................................... 11
--
../data/rfc/rfc1486.txt-
../data/rfc/rfc1486.txt- *.6.9.5.1.4.1.tpc.int. IN MX 10 dbc.mtview.ca.us.
../data/rfc/rfc1486.txt-
../data/rfc/rfc1486.txt- could be used.
../data/rfc/rfc1486.txt-
../data/rfc/rfc1486.txt:3.2. Accounting and Privacy
../data/rfc/rfc1486.txt-
../data/rfc/rfc1486.txt: There is no accounting nor settlement in the experiment; however,
../data/rfc/rfc1486.txt- participating sites may implement access control to prevent abuse.
../data/rfc/rfc1486.txt- Records may be kept for auditing purposes; however, the privacy of a
../data/rfc/rfc1486.txt- participant's printing should be honored. As such, any auditing
../data/rfc/rfc1486.txt- should contain at most this information:
../data/rfc/rfc1486.txt-
--
../data/rfc/rfc1486.txt-
../data/rfc/rfc1486.txt- o determining which content-types and character sets are
../data/rfc/rfc1486.txt- supported by a remote printer server;
../data/rfc/rfc1486.txt-
../data/rfc/rfc1486.txt- o introduction of authentication, integrity, privacy,
../data/rfc/rfc1486.txt: authorization, and accounting services;
../data/rfc/rfc1486.txt-
../data/rfc/rfc1486.txt- o preferential selection of a remote printer server; and,
../data/rfc/rfc1486.txt-
../data/rfc/rfc1486.txt- o aggregation of multiple print recipients in a single
../data/rfc/rfc1486.txt- message.
--
../data/rfc/rfc7679.txt- more detail elsewhere; we encourage others to do so as well.}
../data/rfc/rfc7679.txt-
../data/rfc/rfc7679.txt-3.7. Errors and Uncertainties
../data/rfc/rfc7679.txt-
../data/rfc/rfc7679.txt- The description of any specific measurement method should include an
../data/rfc/rfc7679.txt: accounting and analysis of various sources of error or uncertainty.
../data/rfc/rfc7679.txt- The Framework document provides general guidance on this point, but
../data/rfc/rfc7679.txt- we note here the following specifics related to delay metrics:
../data/rfc/rfc7679.txt-
../data/rfc/rfc7679.txt- o Errors or uncertainties due to uncertainties in the clocks of the
../data/rfc/rfc7679.txt- Src and Dst hosts.
--
../data/rfc/rfc7679.txt- o Errors or uncertainties due to the difference between 'wire time'
../data/rfc/rfc7679.txt- and 'host time'.
../data/rfc/rfc7679.txt-
../data/rfc/rfc7679.txt- In addition, the loss threshold may affect the results. Each of
../data/rfc/rfc7679.txt- these are discussed in more detail below, along with a section
../data/rfc/rfc7679.txt: (Section 3.7.3) on accounting for these errors and uncertainties.
../data/rfc/rfc7679.txt-
../data/rfc/rfc7679.txt-3.7.1. Errors or Uncertainties Related to Clocks
../data/rfc/rfc7679.txt-
../data/rfc/rfc7679.txt- The uncertainty in a measurement of one-way delay is related, in
../data/rfc/rfc7679.txt- part, to uncertainties in the clocks of the Src and Dst hosts. In
--
../data/rfc/rfc5777.txt-10. IANA Considerations
../data/rfc/rfc5777.txt-
../data/rfc/rfc5777.txt-10.1. AVP Codes
../data/rfc/rfc5777.txt-
../data/rfc/rfc5777.txt- IANA has allocated codes from the "AVP Codes" registry under
../data/rfc/rfc5777.txt: Authentication, Authorization, and Accounting (AAA) Parameters for
../data/rfc/rfc5777.txt- the following AVPs that are defined in this document.
../data/rfc/rfc5777.txt-
../data/rfc/rfc5777.txt- +-------------------------------------------------------------------+
../data/rfc/rfc5777.txt- | AVP Section |
../data/rfc/rfc5777.txt- | Attribute Name Code Defined Data Type |
--
../data/rfc/rfc5777.txt- +-------------------------------------------------------------------+
../data/rfc/rfc5777.txt-
../data/rfc/rfc5777.txt-10.2. QoS-Semantics IANA Registry
../data/rfc/rfc5777.txt-
../data/rfc/rfc5777.txt- IANA has allocated a new registry under Authentication,
../data/rfc/rfc5777.txt: Authorization, and Accounting (AAA) Parameters for the QoS-Semantics
../data/rfc/rfc5777.txt- AVP. The following values are allocated by this specification:
../data/rfc/rfc5777.txt-
../data/rfc/rfc5777.txt- (0): QoS-Desired
../data/rfc/rfc5777.txt- (1): QoS-Available
../data/rfc/rfc5777.txt- (2): QoS-Delivered
--
../data/rfc/rfc5777.txt- policy [RFC5226].
../data/rfc/rfc5777.txt-
../data/rfc/rfc5777.txt-10.3. Action
../data/rfc/rfc5777.txt-
../data/rfc/rfc5777.txt- IANA has allocated a new registry under Authentication,
../data/rfc/rfc5777.txt: Authorization, and Accounting (AAA) Parameters for the Treatment-
../data/rfc/rfc5777.txt- Action AVP. The following values are allocated by this
../data/rfc/rfc5777.txt- specification:
../data/rfc/rfc5777.txt-
../data/rfc/rfc5777.txt- 0: drop
../data/rfc/rfc5777.txt- 1: shape
--
../data/rfc/rfc2063.txt- for measuring and understanding the network's traffic flows. This
../data/rfc/rfc2063.txt- information is useful for many purposes, as mentioned in section 1
../data/rfc/rfc2063.txt- (above).
../data/rfc/rfc2063.txt-
../data/rfc/rfc2063.txt- The following sections outline a model for traffic flow measurement,
../data/rfc/rfc2063.txt: which draws from working drafts of the OSI accounting model [2].
../data/rfc/rfc2063.txt- Future extensions are anticipated as the model is refined to address
../data/rfc/rfc2063.txt- additional protocol layers.
../data/rfc/rfc2063.txt-
../data/rfc/rfc2063.txt-2.1 Meters and Traffic Flows
../data/rfc/rfc2063.txt-
--
../data/rfc/rfc2063.txt- Last Collect Time TimeTicks
../data/rfc/rfc2063.txt-
../data/rfc/rfc2063.txt-8 Acknowledgments
../data/rfc/rfc2063.txt-
../data/rfc/rfc2063.txt- This document was initially produced under the auspices of the IETF's
../data/rfc/rfc2063.txt: Internet Accounting Working Group with assistance from SNMP, RMON and
../data/rfc/rfc2063.txt- SAAG working groups. This version documents the implementation work
../data/rfc/rfc2063.txt: done by the Internet Accounting Working Group, and is intended to
../data/rfc/rfc2063.txt- provide a starting point for the Realtime Traffic Flow Measurement
../data/rfc/rfc2063.txt- Working Group. Particular thanks are due to Stephen Stibler (IBM
../data/rfc/rfc2063.txt- Research) for his patient and careful comments during the preparation
../data/rfc/rfc2063.txt- of this memo.
../data/rfc/rfc2063.txt-
--
../data/rfc/rfc2063.txt-RFC 2063 Traffic Flow Measurement: Architecture January 1997
../data/rfc/rfc2063.txt-
../data/rfc/rfc2063.txt-
../data/rfc/rfc2063.txt-9 References
../data/rfc/rfc2063.txt-
../data/rfc/rfc2063.txt: [1] Mills, C., Hirsch, G. and G. Ruth, "Internet Accounting
../data/rfc/rfc2063.txt- Background", RFC 1272, Bolt Beranek and Newman Inc., Meridian
../data/rfc/rfc2063.txt- Technology Corporation, November 1991.
../data/rfc/rfc2063.txt-
../data/rfc/rfc2063.txt- [2] International Standards Organisation (ISO), "Management
../data/rfc/rfc2063.txt- Framework," Part 4 of Information Processing Systems Open
--
../data/rfc/rfc7046.txt-
../data/rfc/rfc7046.txt- sec-credentials: used to implement security mechanisms (e.g., to
../data/rfc/rfc7046.txt- authorize Multicast Group access or authenticate multicast
../data/rfc/rfc7046.txt- operations). This parameter is optional. "alg" represents the
../data/rfc/rfc7046.txt- security algorithm in use. "val" represents the actual value for
../data/rfc/rfc7046.txt: Authentication, Authorization, and Accounting (AAA). Note that
../data/rfc/rfc7046.txt- security credentials may carry a distinct technical meaning w.r.t.
../data/rfc/rfc7046.txt- AAA schemes and may differ between group members. Hence, the
../data/rfc/rfc7046.txt- sec-credentials are not considered part of the Group Name.
../data/rfc/rfc7046.txt-
../data/rfc/rfc7046.txt-
--
../data/rfc/rfc7652.txt-6.6. MTU Considerations
../data/rfc/rfc7652.txt-
../data/rfc/rfc7652.txt- EAP methods are responsible for MTU handling, so no special
../data/rfc/rfc7652.txt- facilities are required in PCP to deal with MTU issues.
../data/rfc/rfc7652.txt- Specifically, EAP lower layers indicate to EAP methods and
../data/rfc/rfc7652.txt: Authentication, Authorization, and Accounting (AAA) servers the MTU
../data/rfc/rfc7652.txt- of the lower layer. EAP methods such as EAP-TLS [RFC5216], TEAP
../data/rfc/rfc7652.txt- [RFC7170], and others that are likely to exceed reasonable MTUs
../data/rfc/rfc7652.txt- provide support for fragmentation and reassembly. Others, such as
../data/rfc/rfc7652.txt- EAP - Generalized Pre-Shared Key (EAP-GPSK) [RFC5433], assume that
../data/rfc/rfc7652.txt- they will never send packets larger than the MTU and use small EAP
--
../data/rfc/rfc5069.txt- to gain faster service by blocking others' competing calls for
../data/rfc/rfc5069.txt- help.
../data/rfc/rfc5069.txt-
../data/rfc/rfc5069.txt- o to gain fraudulent use of services, by using an emergency
../data/rfc/rfc5069.txt- identifier to bypass normal authentication, authorization, and
../data/rfc/rfc5069.txt: accounting procedures.
../data/rfc/rfc5069.txt-
../data/rfc/rfc5069.txt- o to divert emergency calls to non-emergency sites. This is a form
../data/rfc/rfc5069.txt- of a denial-of-service attack similar to the first item, but quite
../data/rfc/rfc5069.txt- likely more confusing for the caller himself or herself since the
../data/rfc/rfc5069.txt- caller expects to talk to a PSAP operator but instead gets
--
../data/rfc/rfc1681.txt-Bellovin [Page 2]
../data/rfc/rfc1681.txt-
../data/rfc/rfc1681.txt-RFC 1681 On Many Addresses per Host August 1994
../data/rfc/rfc1681.txt-
../data/rfc/rfc1681.txt-
../data/rfc/rfc1681.txt:Accounting and Billing
../data/rfc/rfc1681.txt-
../data/rfc/rfc1681.txt- For better or worse, some parts of the Internet are moving towards
../data/rfc/rfc1681.txt- usage-sensitive charging. At least four charging schemes seem
../data/rfc/rfc1681.txt- possible; doubtless, the marketeers in charge of such things can and
../data/rfc/rfc1681.txt- will come up with more.
--
../data/rfc/rfc1681.txt- It may be useful to assign each user on a host a separate IP address,
../data/rfc/rfc1681.txt- for the duration of the login session. This has a number of
../data/rfc/rfc1681.txt- advantages.
../data/rfc/rfc1681.txt-
../data/rfc/rfc1681.txt- The first ties in with the charging scheme given above. Usage-
../data/rfc/rfc1681.txt: sensitive accounting today is done by routers, and they have no
../data/rfc/rfc1681.txt- notion of who is using the hosts. If each user had a separate IP
../data/rfc/rfc1681.txt: address, we could continue to gather the accounting data at the
../data/rfc/rfc1681.txt- router. The host would simply have to record the address
../data/rfc/rfc1681.txt- assignments; billing could be done offline.
../data/rfc/rfc1681.txt-
../data/rfc/rfc1681.txt- Similarly, different classes of users could have different forms of
../data/rfc/rfc1681.txt- addresses. Those with hard-money accounts might have some bits set
--
../data/rfc/rfc5423.txt- 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
../data/rfc/rfc5423.txt- 3. Event Model . . . . . . . . . . . . . . . . . . . . . . . . . 4
../data/rfc/rfc5423.txt- 4. Event Types . . . . . . . . . . . . . . . . . . . . . . . . . 5
../data/rfc/rfc5423.txt- 4.1. Message Addition and Deletion . . . . . . . . . . . . . . 5
../data/rfc/rfc5423.txt- 4.2. Message Flags . . . . . . . . . . . . . . . . . . . . . . 7
../data/rfc/rfc5423.txt: 4.3. Access Accounting . . . . . . . . . . . . . . . . . . . . 8
../data/rfc/rfc5423.txt- 4.4. Mailbox Management . . . . . . . . . . . . . . . . . . . . 8
../data/rfc/rfc5423.txt- 5. Event Parameters . . . . . . . . . . . . . . . . . . . . . . . 10
../data/rfc/rfc5423.txt- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
../data/rfc/rfc5423.txt- 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
../data/rfc/rfc5423.txt- 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
--
../data/rfc/rfc5423.txt-Gellens & Newman Standards Track [Page 7]
../data/rfc/rfc5423.txt-
../data/rfc/rfc5423.txt-RFC 5423 Internet Message Store Events March 2009
../data/rfc/rfc5423.txt-
../data/rfc/rfc5423.txt-
../data/rfc/rfc5423.txt:4.3. Access Accounting
../data/rfc/rfc5423.txt-
../data/rfc/rfc5423.txt: This section lists events related to message store access accounting.
../data/rfc/rfc5423.txt-
../data/rfc/rfc5423.txt- Login
../data/rfc/rfc5423.txt- A user has logged into the system via IMAP, HTTP, POP, or some
../data/rfc/rfc5423.txt- other mechanism.
../data/rfc/rfc5423.txt-
--
../data/rfc/rfc6736.txt- of Network Address Translators and Network Address and Port
../data/rfc/rfc6736.txt- Translators, which are added to networks to cope with IPv4 address
../data/rfc/rfc6736.txt- space depletion. This Diameter application allows external devices
../data/rfc/rfc6736.txt- to configure and manage a Network Address Translator device --
../data/rfc/rfc6736.txt- expanding the existing Diameter-based Authentication, Authorization,
../data/rfc/rfc6736.txt: and Accounting (AAA) and policy control capabilities with a Network
../data/rfc/rfc6736.txt- Address Translator and Network Address and Port Translator control
../data/rfc/rfc6736.txt- component. These external devices can be network elements in the
../data/rfc/rfc6736.txt- data plane such as a Network Access Server, or can be more
../data/rfc/rfc6736.txt- centralized control plane devices such as AAA-servers. This Diameter
../data/rfc/rfc6736.txt- application establishes a context to commonly identify and manage
--
../data/rfc/rfc6736.txt- Network Address and Port Translator device. This includes, for
../data/rfc/rfc6736.txt- example, the control of the total number of Network Address
../data/rfc/rfc6736.txt- Translator bindings allowed or the allocation of a specific Network
../data/rfc/rfc6736.txt- Address Translator binding for a particular endpoint. In addition,
../data/rfc/rfc6736.txt- it allows Network Address Translator devices to provide information
../data/rfc/rfc6736.txt: relevant to accounting purposes.
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt-Status of This Memo
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt- This is an Internet Standards Track document.
../data/rfc/rfc6736.txt-
--
../data/rfc/rfc6736.txt- 4.4. Session Termination .......................................20
../data/rfc/rfc6736.txt- 4.5. Session Abort .............................................21
../data/rfc/rfc6736.txt- 4.6. Failure Cases of the DNCA Diameter Peers ..................22
../data/rfc/rfc6736.txt- 5. Use of the Diameter Base Protocol ..............................23
../data/rfc/rfc6736.txt- 5.1. Securing Diameter Messages ................................23
../data/rfc/rfc6736.txt: 5.2. Accounting Functionality ..................................24
../data/rfc/rfc6736.txt- 5.3. Use of Sessions ...........................................24
../data/rfc/rfc6736.txt- 5.4. Routing Considerations ....................................24
../data/rfc/rfc6736.txt- 5.5. Advertising Application Support ...........................24
../data/rfc/rfc6736.txt- 6. DNCA Commands ..................................................25
../data/rfc/rfc6736.txt- 6.1. NAT-Control-Request (NCR) Command .........................25
--
../data/rfc/rfc6736.txt- 8.7.6. NAT-External-Address AVP ...........................38
../data/rfc/rfc6736.txt- 8.7.7. Max-NAT-Bindings ...................................39
../data/rfc/rfc6736.txt- 8.7.8. NAT-Control-Binding-Template AVP ...................39
../data/rfc/rfc6736.txt- 8.7.9. Duplicate-Session-Id AVP ...........................39
../data/rfc/rfc6736.txt- 8.7.10. NAT-External-Port-Style AVP .......................39
../data/rfc/rfc6736.txt: 9. Accounting Commands ............................................40
../data/rfc/rfc6736.txt: 9.1. NAT Control Accounting Messages ...........................40
../data/rfc/rfc6736.txt: 9.2. NAT Control Accounting AVPs ...............................40
../data/rfc/rfc6736.txt- 9.2.1. NAT-Control-Record .................................41
../data/rfc/rfc6736.txt- 9.2.2. NAT-Control-Binding-Status .........................41
../data/rfc/rfc6736.txt- 9.2.3. Current-NAT-Bindings ...............................41
../data/rfc/rfc6736.txt- 10. AVP Occurrence Tables .........................................41
../data/rfc/rfc6736.txt- 10.1. DNCA AVP Table for NAT Control Initial and Update
../data/rfc/rfc6736.txt- Requests .................................................42
../data/rfc/rfc6736.txt- 10.2. DNCA AVP Table for Session Query Requests ................43
../data/rfc/rfc6736.txt: 10.3. DNCA AVP Table for Accounting Messages ...................43
../data/rfc/rfc6736.txt- 11. IANA Considerations ...........................................44
../data/rfc/rfc6736.txt- 11.1. Application Identifier ...................................44
../data/rfc/rfc6736.txt- 11.2. Command Codes ............................................44
../data/rfc/rfc6736.txt- 11.3. AVP Codes ................................................44
../data/rfc/rfc6736.txt- 11.4. Result-Code AVP Values ...................................44
--
../data/rfc/rfc6736.txt- application allowing providers to control the behavior of NAT and
../data/rfc/rfc6736.txt- NAPT devices that implement IPv4-to-IPv4 network address and port
../data/rfc/rfc6736.txt- translation [RFC2663] as well as stateful IPv6-to-IPv4 address family
../data/rfc/rfc6736.txt- translation as defined in [RFC2663], [RFC6145], and [RFC6146]. The
../data/rfc/rfc6736.txt- use of a Diameter application allows for simple integration into the
../data/rfc/rfc6736.txt: existing Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc6736.txt- environment of a provider.
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt- The Diameter Network address and port translation Control Application
../data/rfc/rfc6736.txt- (DNCA) offers the following capabilities:
../data/rfc/rfc6736.txt-
--
../data/rfc/rfc6736.txt- contains a description of the IP address pool(s) to be used, for
../data/rfc/rfc6736.txt- example, a list of IP-subnets. Such external address pools can
../data/rfc/rfc6736.txt- be used to select the external IP address in NAPT/NAT-bindings
../data/rfc/rfc6736.txt- for multiple subscribers.
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt: 4. Generates reports and accounting records: Reports established
../data/rfc/rfc6736.txt- bindings for a particular endpoint. The collected information is
../data/rfc/rfc6736.txt: used by accounting systems for statistical purposes.
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt- 5. Queries and retrieves details about bindings on demand: This
../data/rfc/rfc6736.txt: feature complements the previously mentioned accounting
../data/rfc/rfc6736.txt- functionality (see item 4). This feature can be used by an
../data/rfc/rfc6736.txt- entity to find NAT-bindings belonging to one or multiple
../data/rfc/rfc6736.txt- endpoints on the NAT device. The entity is not required to
../data/rfc/rfc6736.txt- create a DNCA control session to perform the query but would,
../data/rfc/rfc6736.txt- obviously, still need to create a Diameter session complying to
--
../data/rfc/rfc6736.txt- This document is structured as follows: Section 2 lists terminology,
../data/rfc/rfc6736.txt- while Section 3 provides an introduction to DNCA and its overall
../data/rfc/rfc6736.txt- deployment framework. Sections 3.2 to 8 cover DNCA specifics, with
../data/rfc/rfc6736.txt- Section 3.2 describing session management, Section 5 the use of the
../data/rfc/rfc6736.txt- Diameter base protocol, Section 6 new commands, Section 8 Attribute
../data/rfc/rfc6736.txt: Value Pairs (AVPs) used, and Section 9 accounting aspects.
../data/rfc/rfc6736.txt- Section 10 presents AVP occurrence tables. IANA and security
../data/rfc/rfc6736.txt- considerations are addressed in Sections 11 and 12, respectively.
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt-2. Conventions
../data/rfc/rfc6736.txt-
--
../data/rfc/rfc6736.txt- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
../data/rfc/rfc6736.txt- document are to be interpreted as described in [RFC2119].
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt- Abbreviations and terminology used in this document:
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt: AAA: Authentication, Authorization, Accounting
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt- DNCA: Diameter Network address and port translation Control
../data/rfc/rfc6736.txt- Application
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt- Endpoint: Managed entity of the DNCA. An endpoint represents a
--
../data/rfc/rfc6736.txt- resides within the NAT device, the other DNCA Diameter peer resides
../data/rfc/rfc6736.txt- within a NAT controller (discussed in Section 3.3). DNCA allows per-
../data/rfc/rfc6736.txt- endpoint control and management of NAT within the NAT device. Based
../data/rfc/rfc6736.txt- on Diameter, DNCA integrates well with the suite of Diameter
../data/rfc/rfc6736.txt- applications deployed for per-endpoint authentication, authorization,
../data/rfc/rfc6736.txt: accounting, and policy control in service provider networks.
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt- DNCA offers:
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt- o Request and answer commands to control the allowed number of NAT-
../data/rfc/rfc6736.txt- bindings per endpoint, to request the allocation of specific
--
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt-RFC 6736 Diameter NAT Control Application October 2012
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt- o Unique identification of an endpoint on a NAT device, AAA-server,
../data/rfc/rfc6736.txt: and NAS to simplify correlation of accounting data streams.
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt- DNCA allows controlling the behavior of a NAT device on a per-
../data/rfc/rfc6736.txt- endpoint basis during initial session establishment and at later
../data/rfc/rfc6736.txt- stages by providing an update procedure for already established
../data/rfc/rfc6736.txt- sessions. Using DNCA, per-endpoint NAT-binding information can be
../data/rfc/rfc6736.txt: retrieved using either accounting mechanisms or an explicit session
../data/rfc/rfc6736.txt- query to the NAT.
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt-3.3. Deployment Scenarios for DNCA
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt- DNCA can be deployed in different ways. DNCA supports deployments
--
../data/rfc/rfc6736.txt- Any deployment MUST ensure that, for any given endpoint, only a
../data/rfc/rfc6736.txt- single DNCA NAT controller and is active at any point in time. This
../data/rfc/rfc6736.txt- is to ensure that NAT devices controlled by multiple NAT controllers
../data/rfc/rfc6736.txt- do not receive conflicting control requests for a particular endpoint
../data/rfc/rfc6736.txt- or that they would not be unclear about to which NAT controller to
../data/rfc/rfc6736.txt: send accounting information. Operational considerations MAY require
../data/rfc/rfc6736.txt- an operator to use alternate control mechanisms or protocols such as
../data/rfc/rfc6736.txt- SNMP or manual configuration via a CLI to apply per-endpoint NAT-
../data/rfc/rfc6736.txt- specific configuration, for example, static NAT-bindings. For these
../data/rfc/rfc6736.txt- cases, the NAT device MUST allow the operator to configure a policy
../data/rfc/rfc6736.txt- on how configuration conflicts are resolved. Such a policy could
--
../data/rfc/rfc6736.txt- for environments where minimal changes to the existing AAA deployment
../data/rfc/rfc6736.txt- are desired. The NAS and the NAT device are Diameter peers
../data/rfc/rfc6736.txt- supporting the DNCA. The Diameter peer within the NAS, performing
../data/rfc/rfc6736.txt- the role of the NAT controller, initiates and manages sessions with
../data/rfc/rfc6736.txt- the NAT device, exchanges NAT-specific configuration information, and
../data/rfc/rfc6736.txt: handles reporting and accounting information. The NAS receives
../data/rfc/rfc6736.txt: reporting and accounting information from the NAT device. With this
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt-Brockners, et al. Standards Track [Page 10]
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt-RFC 6736 Diameter NAT Control Application October 2012
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt: information, the NAS can provide a single accounting record for the
../data/rfc/rfc6736.txt: endpoint. A system correlating the accounting information received
../data/rfc/rfc6736.txt- from the NAS and NAT device would not be needed.
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt- An example network attachment for an integrated NAT deployment can be
../data/rfc/rfc6736.txt- described as follows: an endpoint connects to the network, with the
../data/rfc/rfc6736.txt- NAS being the point of attachment. After successful authentication,
--
../data/rfc/rfc6736.txt- and sends relevant authorization and configuration information for
../data/rfc/rfc6736.txt- the particular endpoint to the NAT device. This can comprise NAT-
../data/rfc/rfc6736.txt- bindings, which have to be pre-established for the endpoint, or
../data/rfc/rfc6736.txt- management-related configuration, such as the maximum number of NAT-
../data/rfc/rfc6736.txt- bindings allowed for the endpoint. The NAT device sends its per-
../data/rfc/rfc6736.txt: endpoint accounting information to the NAS, which aggregates the
../data/rfc/rfc6736.txt: accounting information received from the NAT device with its local
../data/rfc/rfc6736.txt: accounting information for the endpoint into a single accounting
../data/rfc/rfc6736.txt- stream towards the AAA-server.
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt- +---------+
../data/rfc/rfc6736.txt- | |
../data/rfc/rfc6736.txt- | AAA |
--
../data/rfc/rfc6736.txt- The autonomous deployment approach decouples endpoint management on
../data/rfc/rfc6736.txt- the NAS and NAT device. In the autonomous deployment approach, the
../data/rfc/rfc6736.txt- AAA-system and the NAT device are the Diameter peers running the
../data/rfc/rfc6736.txt- DNCA. The AAA-system also serves as NAT controller. It manages the
../data/rfc/rfc6736.txt- connection to the NAT device, controls the per-endpoint
../data/rfc/rfc6736.txt: configuration, and receives accounting and reporting information from
../data/rfc/rfc6736.txt- the NAT device. Different from the integrated deployment scenario,
../data/rfc/rfc6736.txt- the autonomous deployment scenario does not "hide" the existence of
../data/rfc/rfc6736.txt: the NAT device from the AAA infrastructure. Here, two accounting
../data/rfc/rfc6736.txt- streams are received by the AAA-server for one particular endpoint:
../data/rfc/rfc6736.txt- one from the NAS and one from the NAT device.
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt- +---------+
../data/rfc/rfc6736.txt- | (C) |
--
../data/rfc/rfc6736.txt- always the control-requesting entity: it initiates, updates, or
../data/rfc/rfc6736.txt- terminates the sessions. Sessions are initiated when the NAT
../data/rfc/rfc6736.txt- controller learns about a new endpoint (i.e., host) that requires a
../data/rfc/rfc6736.txt- NAT service. This could be due to, for example, the entity hosting
../data/rfc/rfc6736.txt- the NAT controller receiving authentication, authorization, or
../data/rfc/rfc6736.txt: accounting requests for or from the endpoint. Alternate methods that
../data/rfc/rfc6736.txt- could trigger session setup include local configuration, receipt of a
../data/rfc/rfc6736.txt- packet from a formerly unknown IP address, etc.
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt-4.1. Session Establishment
../data/rfc/rfc6736.txt-
--
../data/rfc/rfc6736.txt- the DNCA Diameter peer within the NAT controller. The DNCA Diameter
../data/rfc/rfc6736.txt- peer sends a Session-Termination-Request (STR) message to its peer
../data/rfc/rfc6736.txt- within the NAT device upon receiving a trigger signal. The source of
../data/rfc/rfc6736.txt- the trigger signal is outside the scope of this document. As part of
../data/rfc/rfc6736.txt- STR-message processing, the DNCA Diameter peer within the NAT device
../data/rfc/rfc6736.txt: MAY send an accounting stop record reporting all bindings. All the
../data/rfc/rfc6736.txt- NAT-bindings belonging to the session MUST be removed, and the
../data/rfc/rfc6736.txt- session state MUST be cleaned up. The DNCA Diameter peer within the
../data/rfc/rfc6736.txt- NAT device MUST notify its DNCA Diameter peer in the NAT controller
../data/rfc/rfc6736.txt- about successful session termination using a Session-Termination-
../data/rfc/rfc6736.txt- Answer (STA) message with Result-Code set to DIAMETER_SUCCESS.
--
../data/rfc/rfc6736.txt- | |
../data/rfc/rfc6736.txt- | |
../data/rfc/rfc6736.txt- | |
../data/rfc/rfc6736.txt- | |
../data/rfc/rfc6736.txt- | |
../data/rfc/rfc6736.txt: | Send accounting stop |
../data/rfc/rfc6736.txt- |<-------------------------------------------|
../data/rfc/rfc6736.txt- | reporting all session bindings |
../data/rfc/rfc6736.txt- | |
../data/rfc/rfc6736.txt- | |
../data/rfc/rfc6736.txt- | Remove NAT-bindings
--
../data/rfc/rfc6736.txt- AVP to report the Session-Id of the existing session. The DNCA
../data/rfc/rfc6736.txt- Diameter peer within the NAT controller MAY send an explicit
../data/rfc/rfc6736.txt- Session-Termination-Request (STR) for the older session, which
../data/rfc/rfc6736.txt- was lost.
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt: * a DNCA Diameter peer MAY receive accounting records for a
../data/rfc/rfc6736.txt- session that does not exist. The DNCA Diameter peer sends an
../data/rfc/rfc6736.txt: accounting answer with the Result-Code set to
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt-Brockners, et al. Standards Track [Page 22]
../data/rfc/rfc6736.txt-
--
../data/rfc/rfc6736.txt- Result-Code set to DIAMETER_UNKNOWN_SESSION_ID, it MAY try to re-
../data/rfc/rfc6736.txt- establish DNCA session or disconnect corresponding access session.
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt- o The DNCA Diameter peer within the NAT controller is unreachable,
../data/rfc/rfc6736.txt- for example, it is detected by Diameter device watchdog messages
../data/rfc/rfc6736.txt: (as defined in Section 5.5 of [RFC6733]) or accounting requests
../data/rfc/rfc6736.txt- from the DNCA Diameter peer fail to get a response, NAT-bindings
../data/rfc/rfc6736.txt- and NAT device state pertaining to that session MUST be cleaned up
../data/rfc/rfc6736.txt- after a grace period that is configurable on the NAT device. The
../data/rfc/rfc6736.txt- grace period can be configured as zero or higher, depending on
../data/rfc/rfc6736.txt- operator preference.
--
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt- o The content of the NCR Command
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt- o Any combination of the above
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt:5.2. Accounting Functionality
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt: Accounting functionality (the accounting session state machine,
../data/rfc/rfc6736.txt- related Command Codes and AVPs) is defined in Section 9.
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt-5.3. Use of Sessions
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt- Each DNCA session MUST have a globally unique Session-Id, as defined
../data/rfc/rfc6736.txt- in [RFC6733], which MUST NOT be changed during the lifetime of the
../data/rfc/rfc6736.txt- DNCA session. The Diameter Session-Id serves as the global endpoint
../data/rfc/rfc6736.txt- identifier. The DNCA Diameter peers maintain state associated with
../data/rfc/rfc6736.txt- the Session-Id. This globally unique Session-Id is used for
../data/rfc/rfc6736.txt: updating, accounting, and terminating the session. A DNCA session
../data/rfc/rfc6736.txt- MUST NOT have more than one outstanding request at any given time. A
../data/rfc/rfc6736.txt- DNCA Diameter peer sends an Abort-Session-Request as defined in
../data/rfc/rfc6736.txt- [RFC6733] if it is unable to maintain sessions due to resource
../data/rfc/rfc6736.txt- limitation.
../data/rfc/rfc6736.txt-
--
../data/rfc/rfc6736.txt-Brockners, et al. Standards Track [Page 39]
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt-RFC 6736 Diameter NAT Control Application October 2012
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt:9. Accounting Commands
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt: The DNCA reuses session-based accounting as defined in the Diameter
../data/rfc/rfc6736.txt- base protocol [RFC6733] to report the bindings per endpoint. This
../data/rfc/rfc6736.txt: reporting is achieved by sending Diameter Accounting-Request (ACR)
../data/rfc/rfc6736.txt- commands [Start, Interim, and Stop] from the DNCA Diameter peer
../data/rfc/rfc6736.txt- within the NAT device to its associated DNCA Diameter peer within the
../data/rfc/rfc6736.txt- NAT controller.
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt- The DNCA Diameter peer within the NAT device sends an ACR Start on
--
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt- The function of correlating the multiple bindings used by an endpoint
../data/rfc/rfc6736.txt- at any given time is relegated to the post processor.
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt- The DNCA Diameter peer within the NAT device may trigger an Interim
../data/rfc/rfc6736.txt: accounting record when the maximum number of bindings, if received in
../data/rfc/rfc6736.txt- an NCR, is reached.
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt:9.1. NAT Control Accounting Messages
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt- The ACR and ACA messages are reused as defined in the Diameter base
../data/rfc/rfc6736.txt- protocol [RFC6733] for exchanging endpoint NAT-binding details
../data/rfc/rfc6736.txt- between the DNCA Diameter peers. The DNCA Application ID is used in
../data/rfc/rfc6736.txt: the accounting commands. The ACR contains one or more optional NAT-
../data/rfc/rfc6736.txt- Control-Record AVPs to report the bindings. The NAT device indicates
../data/rfc/rfc6736.txt- the number of allocated NAT-bindings to the NAT controller using the
../data/rfc/rfc6736.txt- Current-NAT-Bindings AVP. This number needs to match the number of
../data/rfc/rfc6736.txt- bindings identified as active within the NAT-Control-Record AVP.
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt:9.2. NAT Control Accounting AVPs
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt- In addition to AVPs for ACR specified in [RFC6733], the DNCA Diameter
../data/rfc/rfc6736.txt- peer within the NAT device must add the NAT-Control-Record AVP.
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt-
--
../data/rfc/rfc6736.txt- Remove AVPs could be present in an update or initial requests.
../data/rfc/rfc6736.txt- Consider the following examples:
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt- Neither the NAT-Control-Install AVP nor the NAT-Control-Remove AVP
../data/rfc/rfc6736.txt- is present: This could, for example, be the case if the NAT
../data/rfc/rfc6736.txt: controller would only want to receive accounting information but
../data/rfc/rfc6736.txt- not control NAT-bindings.
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt- Only NAT-Control-Install AVP is present: This could, for example,
../data/rfc/rfc6736.txt- be the case if a new NAT-binding is installed for an existing
../data/rfc/rfc6736.txt- session.
--
../data/rfc/rfc6736.txt- |NAT-External-Address 0+ 0 |
../data/rfc/rfc6736.txt- |Current-NAT-Bindings 0 1 |
../data/rfc/rfc6736.txt- |Duplicate-Session-Id 0 0 |
../data/rfc/rfc6736.txt- +-------------------------------------------------------+
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt:10.3. DNCA AVP Table for Accounting Messages
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt- The following table lists DNCA-specific AVPs, which may or may not be
../data/rfc/rfc6736.txt- present in ACR and ACA messages.
../data/rfc/rfc6736.txt- +-------------------+
../data/rfc/rfc6736.txt- | Command Code |
--
../data/rfc/rfc6736.txt- Auth-Application-Id = <DNCA Application ID>
../data/rfc/rfc6736.txt- Origin-Host = "nat-device.example.com"
../data/rfc/rfc6736.txt- Origin-Realm = "example.com"
../data/rfc/rfc6736.txt- Destination-Realm = "example.com"
../data/rfc/rfc6736.txt- Destination-Host = "natC.example.com"
../data/rfc/rfc6736.txt: Accounting-Record-Type = STOP_RECORD
../data/rfc/rfc6736.txt: Accounting-Record-Number = 1
../data/rfc/rfc6736.txt- NAT-Control-Record = {
../data/rfc/rfc6736.txt- NAT-Control-Definition = {
../data/rfc/rfc6736.txt- Protocol = TCP
../data/rfc/rfc6736.txt- Direction = OUT
../data/rfc/rfc6736.txt- NAT-Internal-Address = {
--
../data/rfc/rfc6736.txt- <ACA> ::= < Diameter Header: 271, PXY >
../data/rfc/rfc6736.txt- Session-Id = "natC.example.com:33041;23432;"
../data/rfc/rfc6736.txt- Origin-Host = "natC.example.com"
../data/rfc/rfc6736.txt- Origin-Realm = "example.com"
../data/rfc/rfc6736.txt- Result-Code = DIAMETER_SUCCESS
../data/rfc/rfc6736.txt: Accounting-Record-Type = STOP_RECORD
../data/rfc/rfc6736.txt: Accounting-Record-Number = 1
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt- 6. On receipt of the ACA the NAT device cleans up all NAT-bindings
../data/rfc/rfc6736.txt- and associated session state for the endpoint.
../data/rfc/rfc6736.txt-
../data/rfc/rfc6736.txt- 7. NAT device sends an STA. On receipt of the STA the NAT
--
../data/rfc/rfc5224.txt- This specification assigns the value 314 from the Command Code
../data/rfc/rfc5224.txt- namespace defined in [RFC3588]. See Section 5.4.1.3.1 of [PEM-1-TS]
../data/rfc/rfc5224.txt- to see how the command code is used.
../data/rfc/rfc5224.txt-
../data/rfc/rfc5224.txt- IANA has made the following assignment in the "Authentication,
../data/rfc/rfc5224.txt: Authorization, and Accounting (AAA) Parameters" registry, in the sub-
../data/rfc/rfc5224.txt- registry "Command Codes".
../data/rfc/rfc5224.txt-
../data/rfc/rfc5224.txt- Code Value Name Reference
../data/rfc/rfc5224.txt- -------------- ------------------------------- ---------
../data/rfc/rfc5224.txt- 314 PDR / PDA [RFC5224]
--
../data/rfc/rfc5216.txt- Since the identity presented in the EAP-Response/Identity need not be
../data/rfc/rfc5216.txt- related to the identity presented in the peer certificate, EAP-TLS
../data/rfc/rfc5216.txt- implementations SHOULD NOT require that they be identical. However,
../data/rfc/rfc5216.txt- if they are not identical, the identity presented in the EAP-
../data/rfc/rfc5216.txt- Response/Identity is unauthenticated information, and SHOULD NOT be
../data/rfc/rfc5216.txt: used for access control or accounting purposes.
../data/rfc/rfc5216.txt-
../data/rfc/rfc5216.txt-
../data/rfc/rfc5216.txt-
../data/rfc/rfc5216.txt-
../data/rfc/rfc5216.txt-
--
../data/rfc/rfc5216.txt-
../data/rfc/rfc5216.txt-
../data/rfc/rfc5216.txt-5.2. Peer and Server Identities
../data/rfc/rfc5216.txt-
../data/rfc/rfc5216.txt- The EAP-TLS peer name (Peer-Id) represents the identity to be used
../data/rfc/rfc5216.txt: for access control and accounting purposes. The Server-Id represents
../data/rfc/rfc5216.txt- the identity of the EAP server. Together the Peer-Id and Server-Id
../data/rfc/rfc5216.txt- name the entities involved in deriving the MSK/EMSK.
../data/rfc/rfc5216.txt-
../data/rfc/rfc5216.txt- In EAP-TLS, the Peer-Id and Server-Id are determined from the subject
../data/rfc/rfc5216.txt- or subjectAltName fields in the peer and server certificates. For
--
../data/rfc/rfc2456.txt- is active; and on row deletion is the last state was active, in which
../data/rfc/rfc2456.txt- case the notification indicates that the state is now inactive.
../data/rfc/rfc2456.txt-
../data/rfc/rfc2456.txt- The SNANAU APPN MIB also provides a mechanism for a management
../data/rfc/rfc2456.txt- station to collect traffic statistics on intermediate sessions,
../data/rfc/rfc2456.txt: primarily for accounting purposes. However, when the session is
../data/rfc/rfc2456.txt- terminated, all statistics from the last poll until the session
../data/rfc/rfc2456.txt- termination time are lost, since the row for that session is deleted
../data/rfc/rfc2456.txt- from the appnIsInTable. This MIB defines a notification so that the
../data/rfc/rfc2456.txt- session's final statistics can be sent to a management station. If
../data/rfc/rfc2456.txt- the notification is not delivered, the final session statistics are
--
../data/rfc/rfc2456.txt- The APPN TRAP MIB module contains a group of notifications, and a
../data/rfc/rfc2456.txt- group of supporting objects.
../data/rfc/rfc2456.txt-
../data/rfc/rfc2456.txt- The group of notifications consists of the following notifications:
../data/rfc/rfc2456.txt-
../data/rfc/rfc2456.txt: 1) appnIsrAccountingDataTrap
../data/rfc/rfc2456.txt-
../data/rfc/rfc2456.txt- This notification is generated by an APPN device when an intermediate
../data/rfc/rfc2456.txt: session is terminating, to report the final accounting statistics of
../data/rfc/rfc2456.txt- the session.
../data/rfc/rfc2456.txt-
../data/rfc/rfc2456.txt- 2) appnLocalTgOperStateChangeTrap
../data/rfc/rfc2456.txt-
../data/rfc/rfc2456.txt- This notification identifies a change to the appnLocalTgOperational
--
../data/rfc/rfc2456.txt- This notification identifies a change to the dlurDlusSessnStatus
../data/rfc/rfc2456.txt- object in a row of the SNANAU DLUR MIB dlurDlusTable.
../data/rfc/rfc2456.txt-
../data/rfc/rfc2456.txt- The group of supporting objects contains the appnTrapControl object,
../data/rfc/rfc2456.txt- which controls whether the APPN device generates each type of
../data/rfc/rfc2456.txt: notification. Note that generation of the appnIsrAccountingDataTrap
../data/rfc/rfc2456.txt- is not controlled by this object; instead it is controlled by the
../data/rfc/rfc2456.txt- appnIsInGlobalCtrAdminStatus object in the SNANAU APPN MIB.
../data/rfc/rfc2456.txt-
../data/rfc/rfc2456.txt- Although APPN notification generation could be controlled solely by
../data/rfc/rfc2456.txt- entries in the snmpNotificationMIB, RFC 2273 [9], the appnTrapControl
--
../data/rfc/rfc2456.txt-
../data/rfc/rfc2456.txt--- *********************************************************************
../data/rfc/rfc2456.txt--- Notifications
../data/rfc/rfc2456.txt--- *********************************************************************
../data/rfc/rfc2456.txt-
../data/rfc/rfc2456.txt:appnIsrAccountingDataTrap NOTIFICATION-TYPE
../data/rfc/rfc2456.txt- OBJECTS {
../data/rfc/rfc2456.txt- appnIsInP2SFmdPius,
../data/rfc/rfc2456.txt- appnIsInS2PFmdPius,
../data/rfc/rfc2456.txt- appnIsInP2SNonFmdPius,
../data/rfc/rfc2456.txt- appnIsInS2PNonFmdPius,
--
../data/rfc/rfc2456.txt- DESCRIPTION
../data/rfc/rfc2456.txt- "When it has been enabled, this notification is generated by an
../data/rfc/rfc2456.txt- APPN node whenever an ISR session passing through the node is
../data/rfc/rfc2456.txt- taken down, regardless of whether the session went down
../data/rfc/rfc2456.txt- normally or abnormally. Its purpose is to allow a management
../data/rfc/rfc2456.txt: application (primarily an accounting application) that is
../data/rfc/rfc2456.txt- monitoring the ISR counts to receive the final values of these
../data/rfc/rfc2456.txt- counts, so that the application can properly account for the
../data/rfc/rfc2456.txt- amounts the counts were incremented since the last time the
../data/rfc/rfc2456.txt- application polled them. The appnIsInSessUpTime object
../data/rfc/rfc2456.txt- provides the total amount of time that the session was active.
--
../data/rfc/rfc2456.txt- notifications of that type, subject to further filtering
../data/rfc/rfc2456.txt- resulting from entries in the snmpNotificationMIB. Setting
../data/rfc/rfc2456.txt- this bit to 0 disables generation of notifications of that
../data/rfc/rfc2456.txt- type.
../data/rfc/rfc2456.txt-
../data/rfc/rfc2456.txt: Note that generation of the appnIsrAccountingDataTrap is
../data/rfc/rfc2456.txt- controlled by the appnIsInGlobeCtrAdminStatus object in
../data/rfc/rfc2456.txt- the APPN MIB: if counts of intermediate session traffic
../data/rfc/rfc2456.txt- are being kept at all, then the notification is also enabled."
../data/rfc/rfc2456.txt-
../data/rfc/rfc2456.txt- ::= { appnTrapObjects 1 }
--
../data/rfc/rfc2456.txt- ::= {appnCompliances 2 }
../data/rfc/rfc2456.txt-
../data/rfc/rfc2456.txt--- Units of conformance
../data/rfc/rfc2456.txt-appnTrapMibIsrNotifGroup NOTIFICATION-GROUP
../data/rfc/rfc2456.txt- NOTIFICATIONS {
../data/rfc/rfc2456.txt: appnIsrAccountingDataTrap
../data/rfc/rfc2456.txt- }
../data/rfc/rfc2456.txt- STATUS current
../data/rfc/rfc2456.txt- DESCRIPTION
../data/rfc/rfc2456.txt- "A notification for reporting the final values of the
../data/rfc/rfc2456.txt- APPN MIB's ISR counters."
--
../data/rfc/rfc5415.txt-12.1. CAPWAP Security
../data/rfc/rfc5415.txt-
../data/rfc/rfc5415.txt- As it is currently specified, the CAPWAP protocol sits between the
../data/rfc/rfc5415.txt- security mechanisms specified by the wireless link layer protocol
../data/rfc/rfc5415.txt- (e.g., IEEE 802.11i) and Authentication, Authorization, and
../data/rfc/rfc5415.txt: Accounting (AAA). One goal of CAPWAP is to bootstrap trust between
../data/rfc/rfc5415.txt- the STA and WTP using a series of preestablished trust relationships:
../data/rfc/rfc5415.txt-
../data/rfc/rfc5415.txt- STA WTP AC AAA
../data/rfc/rfc5415.txt- ==============================================
../data/rfc/rfc5415.txt-
--
../data/rfc/rfc5415.txt- automatic key generation and periodic update, or it MAY be
../data/rfc/rfc5415.txt- accomplished manually instead.
../data/rfc/rfc5415.txt-
../data/rfc/rfc5415.txt- Every pairwise combination of WTP and AC on the network SHOULD have a
../data/rfc/rfc5415.txt- unique PSK. This prevents the domino effect (see "Guidance for
../data/rfc/rfc5415.txt: Authentication, Authorization, and Accounting (AAA) Key Management"
../data/rfc/rfc5415.txt- [RFC4962]). If PSKs are tied to specific WTPs, then knowledge of the
../data/rfc/rfc5415.txt- PSK implies a binding to a specified identity that can be authorized.
../data/rfc/rfc5415.txt-
../data/rfc/rfc5415.txt- If PSKs are shared, this binding between device and identity is no
../data/rfc/rfc5415.txt- longer possible. Compromise of one WTP can yield compromise of
--
../data/rfc/rfc5415.txt- [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The
../data/rfc/rfc5415.txt- Addition of Explicit Congestion Notification (ECN)
../data/rfc/rfc5415.txt- to IP", RFC 3168, September 2001.
../data/rfc/rfc5415.txt-
../data/rfc/rfc5415.txt- [RFC3539] Aboba, B. and J. Wood, "Authentication,
../data/rfc/rfc5415.txt: Authorization and Accounting (AAA) Transport
../data/rfc/rfc5415.txt- Profile", RFC 3539, June 2003.
../data/rfc/rfc5415.txt-
../data/rfc/rfc5415.txt- [RFC3629] Yergeau, F., "UTF-8, a transformation format of
../data/rfc/rfc5415.txt- ISO 10646", STD 63, RFC 3629, November 2003.
../data/rfc/rfc5415.txt-
--
../data/rfc/rfc5415.txt- L. Yang, "Objectives for Control and Provisioning
../data/rfc/rfc5415.txt- of Wireless Access Points (CAPWAP)", RFC 4564,
../data/rfc/rfc5415.txt- July 2006.
../data/rfc/rfc5415.txt-
../data/rfc/rfc5415.txt- [RFC4962] Housley, R. and B. Aboba, "Guidance for
../data/rfc/rfc5415.txt: Authentication, Authorization, and Accounting
../data/rfc/rfc5415.txt- (AAA) Key Management", BCP 132, RFC 4962,
../data/rfc/rfc5415.txt- July 2007.
../data/rfc/rfc5415.txt-
../data/rfc/rfc5415.txt- [LWAPP] Calhoun, P., O'Hara, B., Suri, R., Cam Winget, N.,
../data/rfc/rfc5415.txt- Kelly, S., Williams, M., and S. Hares,
--
../data/rfc/rfc1699.txt-Elliott Informational [Page 6]
../data/rfc/rfc1699.txt-
../data/rfc/rfc1699.txt-RFC 1699 Summary of 1600-1699 January 1997
../data/rfc/rfc1699.txt-
../data/rfc/rfc1699.txt-
../data/rfc/rfc1699.txt:1672 Brownless Aug 94 Accounting Requirements for IPng
../data/rfc/rfc1699.txt-
../data/rfc/rfc1699.txt:This white paper discusses accounting requirements for IPng. It
../data/rfc/rfc1699.txt:recommends that all IPng packets carry accounting tags, which would vary
../data/rfc/rfc1699.txt-in size. This memo provides information for the Internet community.
../data/rfc/rfc1699.txt-This memo does not specify an Internet standard of any kind.
../data/rfc/rfc1699.txt-
../data/rfc/rfc1699.txt-
../data/rfc/rfc1699.txt-1671 Carpenter Aug 94 IPng White Paper on Transition and Other
--
../data/rfc/rfc4083.txt- In order to use the 3GPP IMS, a user is assigned a private user
../data/rfc/rfc4083.txt- identity. The home network operator assigns the private user
../data/rfc/rfc4083.txt- identity, which is used to identify the user uniquely from a network
../data/rfc/rfc4083.txt- perspective. The private user identity is used, for example, for
../data/rfc/rfc4083.txt- authentication, authorization, administration, and, possibly,
../data/rfc/rfc4083.txt: accounting purposes. Note that the private user identity is not used
../data/rfc/rfc4083.txt- for routing of SIP messages.
../data/rfc/rfc4083.txt-
../data/rfc/rfc4083.txt- The private user identity is a unique global identity defined by the
../data/rfc/rfc4083.txt- Home Network Operator. The identity takes the form of a Network
../data/rfc/rfc4083.txt- Access Identifier (NAI) as defined in RFC 2486 [6].
--
../data/rfc/rfc6929.txt- We define a new data type in RADIUS, called "integer64", which
../data/rfc/rfc6929.txt- carries a 64-bit unsigned integer in network byte order.
../data/rfc/rfc6929.txt-
../data/rfc/rfc6929.txt- This data type is intended to be used in any situation where there is
../data/rfc/rfc6929.txt- a need to have counters that can count past 2^32. The expected use
../data/rfc/rfc6929.txt: of this data type is within Accounting-Request packets, but this data
../data/rfc/rfc6929.txt- type SHOULD be used in any packet where 32-bit integers are expected
../data/rfc/rfc6929.txt- to be insufficient.
../data/rfc/rfc6929.txt-
../data/rfc/rfc6929.txt- The "integer64" data type can be used in Attributes of any format,
../data/rfc/rfc6929.txt- standard space, extended attributes, TLVs, and VSAs.
--
../data/rfc/rfc6929.txt-
../data/rfc/rfc6929.txt- [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
../data/rfc/rfc6929.txt- "Remote Authentication Dial In User Service (RADIUS)",
../data/rfc/rfc6929.txt- RFC 2865, June 2000.
../data/rfc/rfc6929.txt-
../data/rfc/rfc6929.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc6929.txt-
../data/rfc/rfc6929.txt- [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
../data/rfc/rfc6929.txt- Authentication Dial In User Service)", RFC 3575,
../data/rfc/rfc6929.txt- July 2003.
../data/rfc/rfc6929.txt-
--
../data/rfc/rfc2599.txt-[STANDARDS-TRACK]
../data/rfc/rfc2599.txt-
../data/rfc/rfc2599.txt-
../data/rfc/rfc2599.txt-2513 McCloghrie Feb 1999 Managed Objects for
../data/rfc/rfc2599.txt- Controlling the Collection
../data/rfc/rfc2599.txt: and Storage of Accounting
../data/rfc/rfc2599.txt- Information for Connection-
../data/rfc/rfc2599.txt- Oriented Networks
../data/rfc/rfc2599.txt-
../data/rfc/rfc2599.txt-This memo defines a portion of the Management Information Base (MIB) for
../data/rfc/rfc2599.txt-use with network management protocols in the Internet community. In
../data/rfc/rfc2599.txt-particular, it describes managed objects used for controlling the
../data/rfc/rfc2599.txt:collection and storage of accounting information for connection-oriented
../data/rfc/rfc2599.txt-networks such as ATM. [STANDARDS-TRACK]
../data/rfc/rfc2599.txt-
../data/rfc/rfc2599.txt-
../data/rfc/rfc2599.txt:2512 McCloghrie Feb 1999 Accounting Information for ATM
../data/rfc/rfc2599.txt- Networks
../data/rfc/rfc2599.txt-
../data/rfc/rfc2599.txt-This memo defines a portion of the Management Information Base (MIB) for
../data/rfc/rfc2599.txt-use with network management protocols in the Internet community. This
../data/rfc/rfc2599.txt:memo defines a set of ATM-specific accounting information which can be
../data/rfc/rfc2599.txt-collected for connections on ATM networks. [STANDARDS-TRACK]
../data/rfc/rfc2599.txt-
../data/rfc/rfc2599.txt-
../data/rfc/rfc2599.txt-2511 Myers Mar 1999 Internet X.509 Certificate
../data/rfc/rfc2599.txt- Request Message Format
--
../data/rfc/rfc1045.txt-communication activity for purposes of resource allocation and
../data/rfc/rfc1045.txt-management. For example, when a lock is requested on a file, the lock
../data/rfc/rfc1045.txt-is associated with the process, not the requesting entity, allowing a
../data/rfc/rfc1045.txt-process to use multiple entity identifiers to perform operations without
../data/rfc/rfc1045.txt-lock conflict between these entities. The principal associated with an
../data/rfc/rfc1045.txt:entity specifies the permissions, security and accounting designation
../data/rfc/rfc1045.txt-associated with the entity. The process and principal identifiers are
../data/rfc/rfc1045.txt-included in VMTP solely to make these values available to VMTP users
../data/rfc/rfc1045.txt-with the security and efficiency provided by VMTP. Only the entity
../data/rfc/rfc1045.txt-identifiers are actively used by the protocol.
../data/rfc/rfc1045.txt-
--
../data/rfc/rfc7224.txt- identity ieee8023adLag {
../data/rfc/rfc7224.txt- base iana-interface-type;
../data/rfc/rfc7224.txt- description
../data/rfc/rfc7224.txt- "IEEE 802.3ad Link Aggregate.";
../data/rfc/rfc7224.txt- }
../data/rfc/rfc7224.txt: identity bgppolicyaccounting {
../data/rfc/rfc7224.txt- base iana-interface-type;
../data/rfc/rfc7224.txt- description
../data/rfc/rfc7224.txt: "BGP Policy Accounting.";
../data/rfc/rfc7224.txt- }
../data/rfc/rfc7224.txt-
../data/rfc/rfc7224.txt-
../data/rfc/rfc7224.txt-
../data/rfc/rfc7224.txt-Bjorklund Standards Track [Page 21]
--
../data/rfc/rfc2750.txt-
../data/rfc/rfc2750.txt- 0 = ERR_INFO : Information reporting
../data/rfc/rfc2750.txt- 1 = ERR_WARN : Warning
../data/rfc/rfc2750.txt- 2 = ERR_UNKNOWN : Reason unknown
../data/rfc/rfc2750.txt- 3 = ERR_REJECT : Generic Policy Rejection
../data/rfc/rfc2750.txt: 4 = ERR_EXCEED : Quota or Accounting violation
../data/rfc/rfc2750.txt- 5 = ERR_PREEMPT : Flow was preempted
../data/rfc/rfc2750.txt- 6 = ERR_EXPIRED : Previously installed policy expired (not
../data/rfc/rfc2750.txt- refreshed)
../data/rfc/rfc2750.txt- 7 = ERR_REPLACED: Previous policy data was replaced & caused
../data/rfc/rfc2750.txt- rejection
--
../data/rfc/rfc4778.txt- possible if the attacker has control of a host in the
../data/rfc/rfc4778.txt- communications path between two victim machines, or has
../data/rfc/rfc4778.txt- compromised the routing infrastructure to specifically arrange
../data/rfc/rfc4778.txt- that traffic pass through a compromised machine. There are also
../data/rfc/rfc4778.txt- situations where mirrored traffic (often used for debugging,
../data/rfc/rfc4778.txt: performance monitoring, or accounting purposes) is diverted to a
../data/rfc/rfc4778.txt- compromised machine, which would not necessarily subvert any
../data/rfc/rfc4778.txt- existing topology, and could be harder to detect. In general, the
../data/rfc/rfc4778.txt- goal of a passive attack is to obtain information that the sender
../data/rfc/rfc4778.txt- and receiver would prefer to remain private [RFC3552].
../data/rfc/rfc4778.txt-
--
../data/rfc/rfc4778.txt- o DoS Mitigation
../data/rfc/rfc4778.txt-
../data/rfc/rfc4778.txt-
../data/rfc/rfc4778.txt- In many instances, a specific protocol currently deployed will offer
../data/rfc/rfc4778.txt- a combination of these services. For example, Authentication,
../data/rfc/rfc4778.txt: Authorization, and Accounting (AAA) can offer user authentication,
../data/rfc/rfc4778.txt- user authorization, and audit/logging services, while the Secure
../data/rfc/rfc4778.txt- SHell (SSH) Protocol can provide data origin authentication, data
../data/rfc/rfc4778.txt- integrity, and data confidentiality. The services offered are more
../data/rfc/rfc4778.txt- important than the actual protocol used. Note that access control
../data/rfc/rfc4778.txt- will refer basically to logical access control, i.e., filtering.
--
../data/rfc/rfc4778.txt- usually 30 days. Every authenticated entity via AAA is an individual
../data/rfc/rfc4778.txt- user for greater granularity of control. Note that often the AAA
../data/rfc/rfc4778.txt- server used for OOB management authentication is a separate physical
../data/rfc/rfc4778.txt- device from the AAA server used for in-band management user
../data/rfc/rfc4778.txt- authentication. In some deployments, the AAA servers used for device
../data/rfc/rfc4778.txt: management authentication/authorization/accounting are on separate
../data/rfc/rfc4778.txt- networks to provide a demarcation for any other authentication
../data/rfc/rfc4778.txt- functions.
../data/rfc/rfc4778.txt-
../data/rfc/rfc4778.txt- For backup purposes, there is often a single local database entry for
../data/rfc/rfc4778.txt- authentication that is known to a very limited set of key personnel.
--
../data/rfc/rfc6696.txt- same domain as the peer, it SHOULD initiate an ERP bootstrap exchange
../data/rfc/rfc6696.txt- with the home ER server to obtain the domain name.
../data/rfc/rfc6696.txt-
../data/rfc/rfc6696.txt- The defined ER extensions allow executing ERP with an ER server in
../data/rfc/rfc6696.txt- the home domain. The home ER server may be co-located with a home
../data/rfc/rfc6696.txt: Authentication, Authorization, and Accounting (AAA) server. ERP with
../data/rfc/rfc6696.txt- the home ER server is similar to the ERP exchange described in
../data/rfc/rfc6696.txt- Figure 1.
../data/rfc/rfc6696.txt-
../data/rfc/rfc6696.txt- Peer ER Authenticator Home ER Server
../data/rfc/rfc6696.txt- ==== ================ ==============
--
../data/rfc/rfc6696.txt- [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication
../data/rfc/rfc6696.txt- Protocol Method for 3rd Generation Authentication and Key
../data/rfc/rfc6696.txt- Agreement (EAP-AKA)", RFC 4187, January 2006.
../data/rfc/rfc6696.txt-
../data/rfc/rfc6696.txt- [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
../data/rfc/rfc6696.txt: Authorization, and Accounting (AAA) Key Management",
../data/rfc/rfc6696.txt- BCP 132, RFC 4962, July 2007.
../data/rfc/rfc6696.txt-
../data/rfc/rfc6696.txt- [RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti,
../data/rfc/rfc6696.txt- "Handover Key Management and Re-Authentication Problem
../data/rfc/rfc6696.txt- Statement", RFC 5169, March 2008.
--
../data/rfc/rfc6674.txt- part of the traffic received from an access device is tunneled over
../data/rfc/rfc6674.txt- the softwire to the AFTR. The combination of CID and SWID must be
../data/rfc/rfc6674.txt- unique between the access gateway and AFTR to identify the flows
../data/rfc/rfc6674.txt- associated with an AD. The CID is typically a 32-bit-wide identifier
../data/rfc/rfc6674.txt- and is assigned by the access gateway. It is retrieved either from a
../data/rfc/rfc6674.txt: local or remote (e.g., Authentication, Authorization, and Accounting
../data/rfc/rfc6674.txt- (AAA)) repository. Like the SWID, the embodiment of the CID depends
../data/rfc/rfc6674.txt- on the tunnel mode used and the type of the network connecting the
../data/rfc/rfc6674.txt- access gateway and AFTR. If, for example, GRE [RFC2784] with GRE Key
../data/rfc/rfc6674.txt- and Sequence Number extensions [RFC2890] is used as the softwire
../data/rfc/rfc6674.txt- technology, the network connecting the access gateway and AFTR could
--
../data/rfc/rfc6674.txt- 3. The access gateway creates an access tunnel endpoint. The access
../data/rfc/rfc6674.txt- tunnel links AD and access gateway.
../data/rfc/rfc6674.txt-
../data/rfc/rfc6674.txt- 4. (Optional): The access gateway and the AFTR establish a control
../data/rfc/rfc6674.txt- session between themselves. This session can, for example, be
../data/rfc/rfc6674.txt: used to exchange accounting or NAT-configuration information.
../data/rfc/rfc6674.txt: Accounting information could be supplied to the access gateway,
../data/rfc/rfc6674.txt- AAA/Policy, or other network entities that require information
../data/rfc/rfc6674.txt- about the externally visible address/port pairs of a particular
../data/rfc/rfc6674.txt- access device. The Diameter NAT Control Application
../data/rfc/rfc6674.txt- [NAT-CONTROL] could, for example, be used for this purpose.
../data/rfc/rfc6674.txt-
--
../data/rfc/rfc7843.txt- IGD-PCP IWF. Depending on an actual implementation, the UPnP IGD-PCP
../data/rfc/rfc7843.txt- IWF can then either use the ID of the tunnel in which the UPnP
../data/rfc/rfc7843.txt- message arrived directly as the THIRD_PARTY_ID option for PCP
../data/rfc/rfc7843.txt- requests to the CGN, or it uses the ID of the tunnel to retrieve the
../data/rfc/rfc7843.txt- THIRD_PARTY_ID option from the Authentication, Authorization, and
../data/rfc/rfc7843.txt: Accounting (AAA) server.
../data/rfc/rfc7843.txt-
../data/rfc/rfc7843.txt- To support the latter option, the BRAS needs to register the
../data/rfc/rfc7843.txt- subscriber's tunnel IDs at the AAA server at the time it contacts the
../data/rfc/rfc7843.txt- AAA server for authentication and/or authorization of the subscriber.
../data/rfc/rfc7843.txt- The tunnel IDs to be registered per subscriber at the AAA server may
--
../data/rfc/rfc5169.txt- In many common deployment scenarios, an EAP peer and EAP server
../data/rfc/rfc5169.txt- authenticate each other through a third party known as the pass-
../data/rfc/rfc5169.txt- through authenticator (hereafter referred to as simply
../data/rfc/rfc5169.txt- "authenticator"). The authenticator is responsible for encapsulating
../data/rfc/rfc5169.txt- EAP packets from a network-access technology lower layer within the
../data/rfc/rfc5169.txt: Authentication, Authorization, and Accounting (AAA) protocol. The
../data/rfc/rfc5169.txt- authenticator does not directly participate in the EAP exchange, and
../data/rfc/rfc5169.txt- simply acts as a gateway during the EAP method execution.
../data/rfc/rfc5169.txt-
../data/rfc/rfc5169.txt- After successful authentication, the EAP server transports the MSK to
../data/rfc/rfc5169.txt- the authenticator. Note that this is performed using AAA protocols,
--
../data/rfc/rfc5169.txt- "Extensible Authentication Protocol (EAP)
../data/rfc/rfc5169.txt- Method Requirements for Wireless LANs",
../data/rfc/rfc5169.txt- RFC 4017, March 2005.
../data/rfc/rfc5169.txt-
../data/rfc/rfc5169.txt- [RFC4962] Housley, R. and B. Aboba, "Guidance for
../data/rfc/rfc5169.txt: Authentication, Authorization, and Accounting
../data/rfc/rfc5169.txt- (AAA) Key Management", BCP 132, RFC 4962,
../data/rfc/rfc5169.txt- July 2007.
../data/rfc/rfc5169.txt-
../data/rfc/rfc5169.txt-10.2. Informative References
../data/rfc/rfc5169.txt-
--
../data/rfc/rfc5106.txt- Note, however, that the EAP peer provides its identity in message 2
../data/rfc/rfc5106.txt- in Figure 1 in cleartext. In order to provide identity
../data/rfc/rfc5106.txt- confidentiality as discussed in the previous paragraphs, it is
../data/rfc/rfc5106.txt- necessary to obfuscate the username part of the identity (the realm
../data/rfc/rfc5106.txt- part must stay intact to allow correct message routing by the
../data/rfc/rfc5106.txt: Authentication, Authorization, and Accounting (AAA) infrastructure).
../data/rfc/rfc5106.txt- The EAP server then uses the identity information in message 4. The
../data/rfc/rfc5106.txt- same mechanism is also used by other EAP methods to provide identity
../data/rfc/rfc5106.txt- confidentiality, for example, EAP-TTLS [8].
../data/rfc/rfc5106.txt-
../data/rfc/rfc5106.txt-10.6. Key Strength
--
../data/rfc/rfc3295.txt- The group of notifications consists of the following notifications:
../data/rfc/rfc3295.txt-
../data/rfc/rfc3295.txt- - gsmpSessionDown
../data/rfc/rfc3295.txt-
../data/rfc/rfc3295.txt- This notification is generated when a session is terminating and also
../data/rfc/rfc3295.txt: reports the final accounting statistics of the session.
../data/rfc/rfc3295.txt-
../data/rfc/rfc3295.txt- - gsmpSessionUp
../data/rfc/rfc3295.txt-
../data/rfc/rfc3295.txt- This notification is generated when a new session is established.
../data/rfc/rfc3295.txt-
--
../data/rfc/rfc3295.txt- DESCRIPTION
../data/rfc/rfc3295.txt- "When it has been enabled, this notification is
../data/rfc/rfc3295.txt- generated whenever a session is taken down, regardless
../data/rfc/rfc3295.txt- of whether the session went down normally or not.
../data/rfc/rfc3295.txt- Its purpose is to allow a management application
../data/rfc/rfc3295.txt: (primarily an accounting application) that is
../data/rfc/rfc3295.txt- monitoring the session statistics to receive the final
../data/rfc/rfc3295.txt- values of these counters, so that the application can
../data/rfc/rfc3295.txt- properly account for the amounts the counters were
../data/rfc/rfc3295.txt- incremented since the last time the application polled
../data/rfc/rfc3295.txt- them. The gsmpSessionStartUptime object provides the
--
../data/rfc/rfc8993.txt- a network with no predefined topology, ideally no manual
../data/rfc/rfc8993.txt- configuration of any kind, and with nodes starting up from factory
../data/rfc/rfc8993.txt- condition or after any form of failure or sudden topology change.
../data/rfc/rfc8993.txt-
../data/rfc/rfc8993.txt- Second, network services such as Authentication, Authorization, and
../data/rfc/rfc8993.txt: Accounting (AAA) should also be discovered and not configured.
../data/rfc/rfc8993.txt- Service discovery is required for such tasks. An Autonomic Network
../data/rfc/rfc8993.txt- can leverage existing service discovery functions, use a new
../data/rfc/rfc8993.txt- approach, or use a mixture.
../data/rfc/rfc8993.txt-
../data/rfc/rfc8993.txt- Thus, the discovery mechanism could either be fully integrated with
--
../data/rfc/rfc5176.txt- This document frequently uses the following terms:
../data/rfc/rfc5176.txt-
../data/rfc/rfc5176.txt- Dynamic Authorization Client (DAC)
../data/rfc/rfc5176.txt- The entity originating Change of Authorization (CoA) Requests or
../data/rfc/rfc5176.txt- Disconnect-Requests. While it is possible that the DAC is
../data/rfc/rfc5176.txt: co-resident with a RADIUS authentication or accounting server,
../data/rfc/rfc5176.txt- this need not necessarily be the case.
../data/rfc/rfc5176.txt-
../data/rfc/rfc5176.txt- Dynamic Authorization Server (DAS)
../data/rfc/rfc5176.txt- The entity receiving CoA-Request or Disconnect-Request packets.
../data/rfc/rfc5176.txt- The DAS may be a NAS or a RADIUS proxy.
--
../data/rfc/rfc5176.txt-
../data/rfc/rfc5176.txt- The packet format consists of the following fields: Code, Identifier,
../data/rfc/rfc5176.txt- Length, Authenticator, and Attributes in Type-Length-Value (TLV)
../data/rfc/rfc5176.txt- format. All fields hold the same meaning as those described in
../data/rfc/rfc5176.txt- RADIUS [RFC2865]. The Authenticator field MUST be calculated in the
../data/rfc/rfc5176.txt: same way as is specified for an Accounting-Request in [RFC2866].
../data/rfc/rfc5176.txt-
../data/rfc/rfc5176.txt- 0 1 2 3
../data/rfc/rfc5176.txt- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
../data/rfc/rfc5176.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
../data/rfc/rfc5176.txt- | Code | Identifier | Length |
--
../data/rfc/rfc5176.txt- Request Authenticator
../data/rfc/rfc5176.txt-
../data/rfc/rfc5176.txt- In Request packets, the Authenticator value is a 16-octet MD5
../data/rfc/rfc5176.txt- [RFC1321] checksum, called the Request Authenticator. The
../data/rfc/rfc5176.txt- Request Authenticator is calculated the same way as for an
../data/rfc/rfc5176.txt: Accounting-Request, specified in [RFC2866].
../data/rfc/rfc5176.txt-
../data/rfc/rfc5176.txt- Note that the Request Authenticator of a CoA-Request or
../data/rfc/rfc5176.txt- Disconnect-Request cannot be computed the same way as the
../data/rfc/rfc5176.txt- Request Authenticator of a RADIUS Access-Request, because there
../data/rfc/rfc5176.txt- is no User-Password Attribute in a CoA-Request or Disconnect-
--
../data/rfc/rfc5176.txt- or Disconnect messages, and if so, which messages it can be
../data/rfc/rfc5176.txt- included in and whether it serves as an identification or
../data/rfc/rfc5176.txt- authorization attribute.
../data/rfc/rfc5176.txt-
../data/rfc/rfc5176.txt- Even if a NAS implements an attribute for use with RADIUS
../data/rfc/rfc5176.txt: authentication and accounting, it is possible that it will not
../data/rfc/rfc5176.txt- support inclusion of that attribute within CoA-Request and
../data/rfc/rfc5176.txt- Disconnect-Request packets, given the difference in attribute
../data/rfc/rfc5176.txt- semantics. This is true even for attributes specified as
../data/rfc/rfc5176.txt-
../data/rfc/rfc5176.txt-
--
../data/rfc/rfc5176.txt- To address security concerns described in Section 6.1, either the
../data/rfc/rfc5176.txt- User-Name or Chargeable-User-Identity attribute SHOULD be present in
../data/rfc/rfc5176.txt- Disconnect-Request and CoA-Request packets.
../data/rfc/rfc5176.txt-
../data/rfc/rfc5176.txt- Where a Diameter client utilizes the same Session-Id for both
../data/rfc/rfc5176.txt: authorization and accounting, inclusion of an Acct-Session-Id
../data/rfc/rfc5176.txt- Attribute in a Disconnect-Request or CoA-Request can assist with
../data/rfc/rfc5176.txt- Diameter/RADIUS translation, since Diameter RAR and ASR commands
../data/rfc/rfc5176.txt- include a Session-Id AVP. An Acct-Session-Id Attribute SHOULD be
../data/rfc/rfc5176.txt- included in Disconnect-Request and CoA-Request packets.
../data/rfc/rfc5176.txt-
../data/rfc/rfc5176.txt- A NAS implementing this specification SHOULD send an Acct-Session-Id
../data/rfc/rfc5176.txt- or Acct-Multi-Session-Id Attribute within an Access-Request. Where
../data/rfc/rfc5176.txt- an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not included
../data/rfc/rfc5176.txt- within an Access-Request, the Dynamic Authorization Client will not
../data/rfc/rfc5176.txt- know the Acct-Session-Id or Acct-Multi-Session-Id of the session it
../data/rfc/rfc5176.txt: is attempting to target, unless it also has access to the accounting
../data/rfc/rfc5176.txt- data for that session.
../data/rfc/rfc5176.txt-
../data/rfc/rfc5176.txt- Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not
../data/rfc/rfc5176.txt- present in a CoA-Request or Disconnect-Request, it is possible that
../data/rfc/rfc5176.txt- the User-Name or Chargeable-User-Identity attributes will not be
--
../data/rfc/rfc5176.txt- attributes. If other attributes are included in a Disconnect-
../data/rfc/rfc5176.txt- Request, implementations MUST send a Disconnect-NAK; an Error-Cause
../data/rfc/rfc5176.txt- Attribute with value "Unsupported Attribute" MAY be included.
../data/rfc/rfc5176.txt-
../data/rfc/rfc5176.txt- The DAC may require access to data from RADIUS authentication or
../data/rfc/rfc5176.txt: accounting packets. It uses this data to compose compliant CoA-
../data/rfc/rfc5176.txt- Request or Disconnect-Request packets. For example, as described in
../data/rfc/rfc5176.txt- Section 3.3, a CoA-Request packet containing a Service-Type Attribute
../data/rfc/rfc5176.txt- with a value of "Authorize Only" is required to contain a State
../data/rfc/rfc5176.txt- Attribute. The NAS will subsequently transmit this attribute to the
../data/rfc/rfc5176.txt- RADIUS server in an Access-Request. In order for the DAC to include
--
../data/rfc/rfc5176.txt- attribute value is to remain unchanged. Attributes included in a
../data/rfc/rfc5176.txt- CoA-Request replace all existing values of the same attribute(s).
../data/rfc/rfc5176.txt-
../data/rfc/rfc5176.txt- (Note 4) When included within a successful Disconnect-Request (where
../data/rfc/rfc5176.txt- a Disconnect-ACK is subsequently sent), the Class Attribute SHOULD be
../data/rfc/rfc5176.txt: sent unmodified by the NAS to the RADIUS accounting server in the
../data/rfc/rfc5176.txt: Accounting Stop packet. If the Disconnect-Request is unsuccessful,
../data/rfc/rfc5176.txt- then the Class Attribute is not processed.
../data/rfc/rfc5176.txt-
../data/rfc/rfc5176.txt- (Note 5) When included within a CoA-Request, these attributes
../data/rfc/rfc5176.txt- represent an authorization change request. Where tunnel attributes
../data/rfc/rfc5176.txt- are included within a successful CoA-Request, all existing tunnel
--
../data/rfc/rfc5176.txt- Session-Id AVP and a Re-Auth-Request-Type AVP with value "AUTHORIZE
../data/rfc/rfc5176.txt- ONLY". Then the Diameter/RADIUS gateway will respond to the ensuing
../data/rfc/rfc5176.txt- access request with a response including the authorization attributes
../data/rfc/rfc5176.txt- gleaned from the CoA-Request. To enable translation, the CoA-Request
../data/rfc/rfc5176.txt- SHOULD include a Acct-Session-Id Attribute. If the Diameter client
../data/rfc/rfc5176.txt: uses the same Session-Id for both authorization and accounting, then
../data/rfc/rfc5176.txt- the Diameter/RADIUS gateway can copy the contents of the Acct-
../data/rfc/rfc5176.txt- Session-Id Attribute into the Session-Id AVP; otherwise, it will
../data/rfc/rfc5176.txt- need to map the Acct-Session-Id value to an equivalent Session-Id for
../data/rfc/rfc5176.txt- use within a RAR command.
../data/rfc/rfc5176.txt-
--
../data/rfc/rfc5176.txt-RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008
../data/rfc/rfc5176.txt-
../data/rfc/rfc5176.txt-
../data/rfc/rfc5176.txt- translated to a Disconnect-Request containing Acct-Session-Id and
../data/rfc/rfc5176.txt- User-Name attributes. If the Diameter client utilizes the same
../data/rfc/rfc5176.txt: Session-Id in both authorization and accounting, then the value of
../data/rfc/rfc5176.txt- the Session-ID AVP may be placed in the Acct-Session-Id Attribute;
../data/rfc/rfc5176.txt- otherwise the value of the Session-ID AVP will need to be mapped to
../data/rfc/rfc5176.txt- an appropriate Acct-Session-Id Attribute. To enable translation of a
../data/rfc/rfc5176.txt- Disconnect-Request to an ASR, an Acct-Session-Id Attribute SHOULD be
../data/rfc/rfc5176.txt- present.
../data/rfc/rfc5176.txt-
../data/rfc/rfc5176.txt- If the Diameter client utilizes the same Session-Id in both
../data/rfc/rfc5176.txt: authorization and accounting, then the value of the Acct-Session-Id
../data/rfc/rfc5176.txt- Attribute may be placed into the Session-ID AVP within the ASR;
../data/rfc/rfc5176.txt- otherwise the value of the Acct-Session-Id Attribute will need to be
../data/rfc/rfc5176.txt- mapped to an appropriate Session-ID AVP.
../data/rfc/rfc5176.txt-
../data/rfc/rfc5176.txt- An Abort-Session-Answer (ASA) command is sent in response to an ASR
--
../data/rfc/rfc5176.txt- affecting the sessions of another provider.
../data/rfc/rfc5176.txt-
../data/rfc/rfc5176.txt- A Dynamic Authorization Server MUST silently discard Disconnect-
../data/rfc/rfc5176.txt- Request or CoA-Request packets from untrusted sources. In situations
../data/rfc/rfc5176.txt- where the Dynamic Authorization Client is co-resident with a RADIUS
../data/rfc/rfc5176.txt: authentication or accounting server, a proxy MAY perform a "reverse
../data/rfc/rfc5176.txt- path forwarding" (RPF) check to verify that a Disconnect-Request or
../data/rfc/rfc5176.txt- CoA-Request originates from an authorized Dynamic Authorization
../data/rfc/rfc5176.txt- Client. In addition, it SHOULD be possible to explicitly authorize
../data/rfc/rfc5176.txt- additional sources of Disconnect-Request or CoA-Request packets
../data/rfc/rfc5176.txt- relating to certain classes of sessions. For example, a particular
--
../data/rfc/rfc5176.txt-
../data/rfc/rfc5176.txt- [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens,
../data/rfc/rfc5176.txt- "Remote Authentication Dial In User Service (RADIUS)",
../data/rfc/rfc5176.txt- RFC 2865, June 2000.
../data/rfc/rfc5176.txt-
../data/rfc/rfc5176.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc5176.txt-
../data/rfc/rfc5176.txt- [RFC2869] Rigney, C., Willats W. and P. Calhoun, "RADIUS
../data/rfc/rfc5176.txt- Extensions", RFC 2869, June 2000.
../data/rfc/rfc5176.txt-
../data/rfc/rfc5176.txt- [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC
--
../data/rfc/rfc5176.txt- [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
../data/rfc/rfc5176.txt- M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol
../data/rfc/rfc5176.txt- Support", RFC 2868, June 2000.
../data/rfc/rfc5176.txt-
../data/rfc/rfc5176.txt- [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization
../data/rfc/rfc5176.txt: and Accounting Transport Profile", RFC 3539, June 2003.
../data/rfc/rfc5176.txt-
../data/rfc/rfc5176.txt- [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B.
../data/rfc/rfc5176.txt- Aboba, "Dynamic Authorization Extensions to Remote
../data/rfc/rfc5176.txt- Authentication Dial In User Service (RADIUS)", RFC 3576,
../data/rfc/rfc5176.txt- July 2003.
--
../data/rfc/rfc5448.txt- seeing a re-authentication request with a changed network name, the
../data/rfc/rfc5448.txt- server SHOULD behave as if the re-authentication identifier had been
../data/rfc/rfc5448.txt- unrecognized, and fall back to full authentication. The server
../data/rfc/rfc5448.txt- observes the change in the name by comparing where the fast
../data/rfc/rfc5448.txt- re-authentication and full authentication EAP transactions were
../data/rfc/rfc5448.txt: received at the Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc5448.txt- protocol level.
../data/rfc/rfc5448.txt-
../data/rfc/rfc5448.txt- AT_KDF has any other value
../data/rfc/rfc5448.txt-
../data/rfc/rfc5448.txt- Future variations of key derivation functions may be defined, and
--
../data/rfc/rfc8372.txt-
../data/rfc/rfc8372.txt- When this level of accuracy is required and the traffic between a
../data/rfc/rfc8372.txt- source-destination pair is subject to Equal-Cost Multipath (ECMP), a
../data/rfc/rfc8372.txt- demarcation mechanism is needed to group the packets into batches.
../data/rfc/rfc8372.txt- Once a batch is correlated at both ingress and egress, the packet
../data/rfc/rfc8372.txt: accounting mechanism is then able to operate on the batch of packets
../data/rfc/rfc8372.txt- that can be accounted for at both the packet ingress and the packet
../data/rfc/rfc8372.txt-
../data/rfc/rfc8372.txt-
../data/rfc/rfc8372.txt-
../data/rfc/rfc8372.txt-
../data/rfc/rfc8372.txt-Bryant, et al. Informational [Page 3]
../data/rfc/rfc8372.txt-
../data/rfc/rfc8372.txt-RFC 8372 MPLS Flow Identification May 2018
../data/rfc/rfc8372.txt-
../data/rfc/rfc8372.txt-
../data/rfc/rfc8372.txt: egress. Errors in the accounting are particularly acute in Label
../data/rfc/rfc8372.txt- Switched Paths (LSPs) subjected to ECMP because the network transit
../data/rfc/rfc8372.txt- time will be different for the various ECMP paths since:
../data/rfc/rfc8372.txt-
../data/rfc/rfc8372.txt- 1. the packets may traverse different sets of LSRs;
../data/rfc/rfc8372.txt-
--
../data/rfc/rfc8372.txt- batch represented by a change of identity label will have no impact
../data/rfc/rfc8372.txt- on the ECMP path. If the path member is chosen by reference to an
../data/rfc/rfc8372.txt- entropy label [RFC6790], then changing the batch identifier will not
../data/rfc/rfc8372.txt- result in a change to the chosen ECMP path. ECMP is so pervasive in
../data/rfc/rfc8372.txt- multipoint-to-(multi)point networks that some method of avoiding
../data/rfc/rfc8372.txt: accounting errors introduced by ECMP needs to be supported.
../data/rfc/rfc8372.txt-
../data/rfc/rfc8372.txt-3. Delay Measurement Considerations
../data/rfc/rfc8372.txt-
../data/rfc/rfc8372.txt- Most of the existing delay measurement methods are active methods
../data/rfc/rfc8372.txt- that depend on the extra injected test packet to evaluate the delay
--
../data/rfc/rfc8372.txt-4. Units of Identification
../data/rfc/rfc8372.txt-
../data/rfc/rfc8372.txt- The most basic unit of identification is the identity of the node
../data/rfc/rfc8372.txt- that processed the packet on its entry to the MPLS network. However,
../data/rfc/rfc8372.txt- the required unit of identification may vary depending on the use
../data/rfc/rfc8372.txt: case for accounting, performance measurement, or other types of
../data/rfc/rfc8372.txt- packet observations. In particular, note that there may be a need to
../data/rfc/rfc8372.txt- impose identity at several different layers of the MPLS label stack.
../data/rfc/rfc8372.txt-
../data/rfc/rfc8372.txt-
../data/rfc/rfc8372.txt-
--
../data/rfc/rfc1633.txt-RFC 1633 Integrated Services Architecture June 1994
../data/rfc/rfc1633.txt-
../data/rfc/rfc1633.txt-
../data/rfc/rfc1633.txt- o Classifier
../data/rfc/rfc1633.txt-
../data/rfc/rfc1633.txt: For the purpose of traffic control (and accounting), each
../data/rfc/rfc1633.txt- incoming packet must be mapped into some class; all packets
../data/rfc/rfc1633.txt- in the same class get the same treatment from the packet
../data/rfc/rfc1633.txt- scheduler. This mapping is performed by the classifier.
../data/rfc/rfc1633.txt- Choice of a class may be based upon the contents of the
../data/rfc/rfc1633.txt- existing packet header(s) and/or some additional
--
../data/rfc/rfc1633.txt-Braden, Clark & Shenker [Page 8]
../data/rfc/rfc1633.txt-
../data/rfc/rfc1633.txt-RFC 1633 Integrated Services Architecture June 1994
../data/rfc/rfc1633.txt-
../data/rfc/rfc1633.txt-
../data/rfc/rfc1633.txt: important role in accounting and administrative reporting.
../data/rfc/rfc1633.txt-
../data/rfc/rfc1633.txt- The fourth and final component of our implementation framework is
../data/rfc/rfc1633.txt- a reservation setup protocol, which is necessary to create and
../data/rfc/rfc1633.txt- maintain flow-specific state in the endpoint hosts and in routers
../data/rfc/rfc1633.txt- along the path of a flow. Section discusses a reservation setup
--
../data/rfc/rfc1633.txt- delivered.
../data/rfc/rfc1633.txt-
../data/rfc/rfc1633.txt- 3.4 Usage Feedback
../data/rfc/rfc1633.txt-
../data/rfc/rfc1633.txt- Another important issue in the service is the model for usage
../data/rfc/rfc1633.txt: feedback, also known as "accounting", to prevent abuse of network
../data/rfc/rfc1633.txt- resources. The link-sharing service described earlier can be
../data/rfc/rfc1633.txt- used to provide administratively-imposed limits on usage.
../data/rfc/rfc1633.txt- However, a more free-market model of network access will require
../data/rfc/rfc1633.txt- back-pressure on users for the network resources they reserve.
../data/rfc/rfc1633.txt- This is a highly contentious issue, and we are not prepared to say
--
../data/rfc/rfc6459.txt- decides to establish a PDN connection with a PDN-GW. The UE
../data/rfc/rfc6459.txt- sends an "Attach" request (layer-2) to the base station (BS).
../data/rfc/rfc6459.txt- The BS forwards this Attach request to the MME.
../data/rfc/rfc6459.txt-
../data/rfc/rfc6459.txt- 2. Authentication of the UE with the Authentication, Authorization,
../data/rfc/rfc6459.txt: and Accounting (AAA) server/HSS follows. If the UE is
../data/rfc/rfc6459.txt- authorized to establish a data connection, the process continues
../data/rfc/rfc6459.txt- with the following steps:
../data/rfc/rfc6459.txt-
../data/rfc/rfc6459.txt- 3. The MME sends a "Create Session" request message to the SGW.
../data/rfc/rfc6459.txt- The SGW forwards the Create Session request to the PDN-GW. The
--
../data/rfc/rfc8376.txt-5. Security Considerations
../data/rfc/rfc8376.txt-
../data/rfc/rfc8376.txt- Most LPWAN technologies integrate some authentication or encryption
../data/rfc/rfc8376.txt- mechanisms that were defined outside the IETF. The LPWAN WG may need
../data/rfc/rfc8376.txt- to do work to integrate these mechanisms to unify management. A
../data/rfc/rfc8376.txt: standardized Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc8376.txt- infrastructure [RFC2904] may offer a scalable solution for some of
../data/rfc/rfc8376.txt- the security and management issues for LPWANs. AAA offers
../data/rfc/rfc8376.txt- centralized management that may be of use in LPWANs, for example
../data/rfc/rfc8376.txt- [LoRaWAN-AUTH] and [LoRaWAN-RADIUS] suggest possible security
../data/rfc/rfc8376.txt- processes for a LoRaWAN network. Similar mechanisms may be useful to
--
../data/rfc/rfc5213.txt- messages or sending binding updates. Therefore, the local mobility
../data/rfc/rfc5213.txt- anchor MUST restrict the creation and manipulation of proxy bindings
../data/rfc/rfc5213.txt- to specifically authorized mobile access gateways and prefixes. The
../data/rfc/rfc5213.txt- local mobility anchor MUST be locally configurable to authorize such
../data/rfc/rfc5213.txt- specific combinations. Additional mechanisms, such as a policy store
../data/rfc/rfc5213.txt: or Authentication, Authorization, and Accounting (AAA) may be
../data/rfc/rfc5213.txt- employed, but these are outside the scope of this specification.
../data/rfc/rfc5213.txt-
../data/rfc/rfc5213.txt- Unlike in Mobile IPv6 [RFC3775], these signaling messages do not
../data/rfc/rfc5213.txt- carry either the Home Address destination option or the Type 2
../data/rfc/rfc5213.txt- Routing header, and hence the policy entries and security association
--
../data/rfc/rfc5213.txt- connected to the mobile access gateway, the mobile access gateway MAY
../data/rfc/rfc5213.txt- optimize on the delivery efforts by locally routing the packets and
../data/rfc/rfc5213.txt- by not reverse tunneling them to the mobile node's local mobility
../data/rfc/rfc5213.txt- anchor. The flag EnableMAGLocalRouting MAY be used for controlling
../data/rfc/rfc5213.txt- this behavior. However, in some systems, this may have an
../data/rfc/rfc5213.txt: implication on the mobile node's accounting and policy enforcement as
../data/rfc/rfc5213.txt- the local mobility anchor is not in the path for that traffic and it
../data/rfc/rfc5213.txt: will not be able to apply any traffic policies or do any accounting
../data/rfc/rfc5213.txt- for those flows.
../data/rfc/rfc5213.txt-
../data/rfc/rfc5213.txt- This decision of path optimization SHOULD be based on the policy
../data/rfc/rfc5213.txt- configured on the mobile access gateway, but enforced by the mobile
../data/rfc/rfc5213.txt- node's local mobility anchor. The specific details on how this is
--
../data/rfc/rfc7576.txt- 3. Automatic and Autonomic Aspects of Current IP Networks . . . 3
../data/rfc/rfc7576.txt- 3.1. IP Address Management and DNS . . . . . . . . . . . . . . 3
../data/rfc/rfc7576.txt- 3.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 5
../data/rfc/rfc7576.txt- 3.3. Configuration of Default Router in a Host . . . . . . . . 5
../data/rfc/rfc7576.txt- 3.4. Hostname Lookup . . . . . . . . . . . . . . . . . . . . . 5
../data/rfc/rfc7576.txt: 3.5. User Authentication and Accounting . . . . . . . . . . . 6
../data/rfc/rfc7576.txt- 3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . 6
../data/rfc/rfc7576.txt- 3.7. State Synchronization . . . . . . . . . . . . . . . . . . 7
../data/rfc/rfc7576.txt- 4. Current Non-autonomic Behaviors . . . . . . . . . . . . . . . 7
../data/rfc/rfc7576.txt- 4.1. Building a New Network . . . . . . . . . . . . . . . . . 7
../data/rfc/rfc7576.txt- 4.2. Network Maintenance and Management . . . . . . . . . . . 8
--
../data/rfc/rfc7576.txt-
../data/rfc/rfc7576.txt- configured with the appropriate DNS server addresses. Additionally,
../data/rfc/rfc7576.txt- some networks deploy Multicast DNS [RFC6762] locally to provide
../data/rfc/rfc7576.txt- additional automation of the name space.
../data/rfc/rfc7576.txt-
../data/rfc/rfc7576.txt:3.5. User Authentication and Accounting
../data/rfc/rfc7576.txt-
../data/rfc/rfc7576.txt: Originally, user authentication and accounting was mainly based on
../data/rfc/rfc7576.txt- physical connectivity and the degree of trust that follows from
../data/rfc/rfc7576.txt- direct connectivity. Network operators charged based on the setup of
../data/rfc/rfc7576.txt- dedicated physical links with users. Automated user authentication
../data/rfc/rfc7576.txt- was introduced by the Point-to-Point Protocol [RFC1661], [RFC1994]
../data/rfc/rfc7576.txt- and RADIUS protocol [RFC2865] [RFC2866] in the early 1990s. As long
../data/rfc/rfc7576.txt- as a user completes online authentication through the RADIUS
../data/rfc/rfc7576.txt: protocol, the accounting for that user starts on the corresponding
../data/rfc/rfc7576.txt: Authentication, Authorization, and Accounting (AAA) server
../data/rfc/rfc7576.txt- automatically. This mechanism enables business models with charging
../data/rfc/rfc7576.txt- based on the amount of traffic or time. However, user authentication
../data/rfc/rfc7576.txt- information continues to be manually managed by network
../data/rfc/rfc7576.txt- administrators. It also becomes complex in the case of mobile users
../data/rfc/rfc7576.txt- who roam between operators, since prior relationships between the
--
../data/rfc/rfc7576.txt-
../data/rfc/rfc7576.txt-RFC 7576 Autonomic Networking Gap Analysis June 2015
../data/rfc/rfc7576.txt-
../data/rfc/rfc7576.txt-
../data/rfc/rfc7576.txt- each device and each protocol, set up central user authentication and
../data/rfc/rfc7576.txt: accounting policies and databases, design and deploy security
../data/rfc/rfc7576.txt- mechanisms, etc.
../data/rfc/rfc7576.txt-
../data/rfc/rfc7576.txt- Overall, these jobs are quite complex work that cannot become fully
../data/rfc/rfc7576.txt- autonomic in the foreseeable future. However, part of these jobs may
../data/rfc/rfc7576.txt- be able to become autonomic, such as detailed device and protocol
--
../data/rfc/rfc7576.txt- [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
../data/rfc/rfc7576.txt- "Remote Authentication Dial In User Service (RADIUS)",
../data/rfc/rfc7576.txt- RFC 2865, DOI 10.17487/RFC2865, June 2000,
../data/rfc/rfc7576.txt- <http://www.rfc-editor.org/info/rfc2865>.
../data/rfc/rfc7576.txt-
../data/rfc/rfc7576.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866,
../data/rfc/rfc7576.txt- DOI 10.17487/RFC2866, June 2000,
../data/rfc/rfc7576.txt- <http://www.rfc-editor.org/info/rfc2866>.
../data/rfc/rfc7576.txt-
../data/rfc/rfc7576.txt- [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
../data/rfc/rfc7576.txt- C., and M. Carney, "Dynamic Host Configuration Protocol
--
../data/rfc/rfc6123.txt- Manageability issues are often referred to under the collective
../data/rfc/rfc6123.txt- acronym, FCAPS [X.700], which stands for the following:
../data/rfc/rfc6123.txt-
../data/rfc/rfc6123.txt- - Fault management
../data/rfc/rfc6123.txt- - Configuration
../data/rfc/rfc6123.txt: - Accounting
../data/rfc/rfc6123.txt- - Performance
../data/rfc/rfc6123.txt- - Security
../data/rfc/rfc6123.txt-
../data/rfc/rfc6123.txt- Conventionally, Security is already covered an Internet-Draft in its
../data/rfc/rfc6123.txt- own Security Considerations section, and this document does not in
--
../data/rfc/rfc5191.txt- is to verify the credentials provided by a PANA client (PaC) and
../data/rfc/rfc5191.txt- authorize network access to the access device. The PAA and the
../data/rfc/rfc5191.txt- EAP authenticator (and optionally the EAP server) are colocated in
../data/rfc/rfc5191.txt- the same node. Note the authentication and authorization
../data/rfc/rfc5191.txt- procedure can, according to the EAP model, also be offloaded to
../data/rfc/rfc5191.txt: the back end Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc5191.txt- infrastructure.
../data/rfc/rfc5191.txt-
../data/rfc/rfc5191.txt-
../data/rfc/rfc5191.txt-
../data/rfc/rfc5191.txt-
--
../data/rfc/rfc5191.txt-
../data/rfc/rfc5191.txt-11.8. Early Termination of a Session
../data/rfc/rfc5191.txt-
../data/rfc/rfc5191.txt- The PANA protocol supports the ability for both the PaC and the PAA
../data/rfc/rfc5191.txt- to transmit a tear-down message before the session lifetime expires.
../data/rfc/rfc5191.txt: This message causes state removal, a stop of the accounting procedure
../data/rfc/rfc5191.txt- and removes the installed per-PaC state on the EP(s). This message
../data/rfc/rfc5191.txt- is cryptographically protected when PANA SA is present.
../data/rfc/rfc5191.txt-
../data/rfc/rfc5191.txt-12. Acknowledgments
../data/rfc/rfc5191.txt-
--
../data/rfc/rfc4297.txt- that avoiding copies reduces CPU time spent on data access from 24%
../data/rfc/rfc4297.txt- to 15% at 370 Mbits/s for a 32 KBytes MTU using an AlphaStation
../data/rfc/rfc4297.txt- XP1000 and a Myrinet adapter [BCF+95]. This is an absolute
../data/rfc/rfc4297.txt- improvement of 9% due to copy avoidance.
../data/rfc/rfc4297.txt-
../data/rfc/rfc4297.txt: The total CPU utilization was 35%, with data access accounting for
../data/rfc/rfc4297.txt- 24%. Thus, the relative importance of reducing copies is 26%. At
../data/rfc/rfc4297.txt- 370 Mbits/s, the system is not very heavily loaded. The relative
../data/rfc/rfc4297.txt- improvement in achievable bandwidth is 34%. This is the improvement
../data/rfc/rfc4297.txt- we would see if copy avoidance were added when the machine was
../data/rfc/rfc4297.txt- saturated by network I/O.
--
../data/rfc/rfc905.txt-
../data/rfc/rfc905.txt-
../data/rfc/rfc905.txt-
../data/rfc/rfc905.txt-
../data/rfc/rfc905.txt-
../data/rfc/rfc905.txt: b) accounting mechanisms;
../data/rfc/rfc905.txt-
../data/rfc/rfc905.txt- c) status exchanges and monitoring of QOS;
../data/rfc/rfc905.txt-
../data/rfc/rfc905.txt- d) blocking;
../data/rfc/rfc905.txt-
--
../data/rfc/rfc2475.txt- properties (e.g., rate) of a traffic stream
../data/rfc/rfc2475.txt- selected by a classifier. The
../data/rfc/rfc2475.txt- instantaneous state of this process may be
../data/rfc/rfc2475.txt- used to affect the operation of a marker,
../data/rfc/rfc2475.txt- shaper, or dropper, and/or may be used for
../data/rfc/rfc2475.txt: accounting and measurement purposes.
../data/rfc/rfc2475.txt-
../data/rfc/rfc2475.txt- Microflow a single instance of an application-to-
../data/rfc/rfc2475.txt- application flow of packets which is
../data/rfc/rfc2475.txt- identified by source address, source port,
../data/rfc/rfc2475.txt- destination address, destination port and
--
../data/rfc/rfc2475.txt- are available in the bucket. The concept of in- and out-of-profile
../data/rfc/rfc2475.txt- can be extended to more than two levels, e.g., multiple levels of
../data/rfc/rfc2475.txt- conformance with a profile may be defined and enforced.
../data/rfc/rfc2475.txt-
../data/rfc/rfc2475.txt- Different conditioning actions may be applied to the in-profile
../data/rfc/rfc2475.txt: packets and out-of-profile packets, or different accounting actions
../data/rfc/rfc2475.txt- may be triggered. In-profile packets may be allowed to enter the DS
../data/rfc/rfc2475.txt- domain without further conditioning; or, alternatively, their DS
../data/rfc/rfc2475.txt- codepoint may be changed. The latter happens when the DS codepoint
../data/rfc/rfc2475.txt- is set to a non-Default value for the first time [DSFIELD], or when
../data/rfc/rfc2475.txt- the packets enter a DS domain that uses a different PHB group or
../data/rfc/rfc2475.txt- codepoint->PHB mapping policy for this traffic stream. Out-of-
../data/rfc/rfc2475.txt- profile packets may be queued until they are in-profile (shaped),
../data/rfc/rfc2475.txt- discarded (policed), marked with a new codepoint (re-marked), or
../data/rfc/rfc2475.txt: forwarded unchanged while triggering some accounting procedure.
../data/rfc/rfc2475.txt- Out-of-profile packets may be mapped to one or more behavior
../data/rfc/rfc2475.txt- aggregates that are "inferior" in some dimension of forwarding
../data/rfc/rfc2475.txt- performance to the BA into which in-profile packets are mapped.
../data/rfc/rfc2475.txt-
../data/rfc/rfc2475.txt- Note that a traffic profile is an optional component of a TCA and its
--
../data/rfc/rfc694.txt- Schedule:
../data/rfc/rfc694.txt-
../data/rfc/rfc694.txt- Comments:
../data/rfc/rfc694.txt-
../data/rfc/rfc694.txt- The TIPs and some RSEXEC servers now are cooperating to perform
../data/rfc/rfc694.txt: TIP user authentication and accounting functions.
../data/rfc/rfc694.txt-
../data/rfc/rfc694.txt- Recent developments:
../data/rfc/rfc694.txt-
../data/rfc/rfc694.txt- Line Processor Protocol
../data/rfc/rfc694.txt-
--
../data/rfc/rfc694.txt-
../data/rfc/rfc694.txt- EXEC (24580,) "The Executive Package"
../data/rfc/rfc694.txt-
../data/rfc/rfc694.txt- This document describes a package that runs in the setting
../data/rfc/rfc694.txt- provided by PCP. It includes procedures and data stores for
../data/rfc/rfc694.txt: user identification, accounting, and usage information.
../data/rfc/rfc694.txt-
../data/rfc/rfc694.txt- Pathname: [BBNB] <NLS>EXEC.TXT
../data/rfc/rfc694.txt-
../data/rfc/rfc694.txt- FILE (24582,) "The File Package"
../data/rfc/rfc694.txt-
--
../data/rfc/rfc694.txt- 1 1 Reserved
../data/rfc/rfc694.txt- 2-71 2-107 Regular Messages
../data/rfc/rfc694.txt- 72-151 110-227 Reserved
../data/rfc/rfc694.txt- 152 230 PARC Universal Protocol
../data/rfc/rfc694.txt- 153 231 TIP Status Reporting
../data/rfc/rfc694.txt: 154 232 TIP Accounting
../data/rfc/rfc694.txt- 155-158 233-236 Internet Protocol
../data/rfc/rfc694.txt- 159-191 237-277 Measurements
../data/rfc/rfc694.txt- 192-195 300-303 Message Switching Protocol
../data/rfc/rfc694.txt- 196-255 304-255 Experimental Protocols
../data/rfc/rfc694.txt-
--
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt-1.2. Terminology
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt- AAA
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt: Authentication, Authorization, and Accounting
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt- AA answer
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt- AA answer generically refers to a service specific authorization and
../data/rfc/rfc4006.txt- authentication answer. AA answer commands are defined in service
--
../data/rfc/rfc4006.txt- Capabilities-Exchange-Request and Capabilities-Exchange-Answer
../data/rfc/rfc4006.txt- command [DIAMBASE].
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt-2. Architecture Models
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt: The current accounting models specified in the Radius Accounting
../data/rfc/rfc4006.txt- [RFC2866] and Diameter base [DIAMBASE] are not sufficient for real-
../data/rfc/rfc4006.txt- time credit-control, where credit-worthiness is to be determined
../data/rfc/rfc4006.txt- prior to service initiation. Also, the existing Diameter
../data/rfc/rfc4006.txt- authorization applications, [NASREQ] and [DIAMMIP], only provide
../data/rfc/rfc4006.txt- service authorization, but do not provide credit authorization for
--
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt- A service element may authenticate and authorize the end user with
../data/rfc/rfc4006.txt- the AAA server by using AAA protocols; e.g., RADIUS or a Diameter
../data/rfc/rfc4006.txt- base protocol with a possible Diameter application.
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt: Accounting protocols such as RADIUS accounting and the Diameter base
../data/rfc/rfc4006.txt: accounting protocol can be used to provide accounting data to the
../data/rfc/rfc4006.txt: accounting server after service is initiated, and to provide possible
../data/rfc/rfc4006.txt- interim reports until service completion. However, for real-time
../data/rfc/rfc4006.txt: credit-control, these authorization and accounting models are not
../data/rfc/rfc4006.txt- sufficient.
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt- When real-time credit-control is required, the credit-control client
../data/rfc/rfc4006.txt- contacts the credit-control server with information about a possible
../data/rfc/rfc4006.txt- service event. The credit-control process is performed to determine
--
../data/rfc/rfc4006.txt-Hakala, et al. Standards Track [Page 23]
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt-RFC 4006 Diameter Credit-Control Application August 2005
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt: accounting protocol and the credit-control protocol can be used in
../data/rfc/rfc4006.txt- parallel. The authorization server may also determine whether the
../data/rfc/rfc4006.txt: parallel accounting stream is required.
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt- The following diagram illustrates the case where both protocols are
../data/rfc/rfc4006.txt- used in parallel and the service element sends credit-control
../data/rfc/rfc4006.txt- messages directly to the credit-control server. More credit-control
../data/rfc/rfc4006.txt- sequence examples are given in Annex A.
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt- Diameter
../data/rfc/rfc4006.txt- End User Service Element AAA Server CC Server
../data/rfc/rfc4006.txt- (CC Client)
../data/rfc/rfc4006.txt: | Registration | AA request/answer(accounting,cc or both)|
../data/rfc/rfc4006.txt- |<----------------->|<------------------>| |
../data/rfc/rfc4006.txt- | : | | |
../data/rfc/rfc4006.txt- | : | | |
../data/rfc/rfc4006.txt- | Service Request | | |
../data/rfc/rfc4006.txt- |------------------>| | |
../data/rfc/rfc4006.txt- | | CCR(Initial,Credit-Control AVPs) |
../data/rfc/rfc4006.txt- | +|---------------------------------------->|
../data/rfc/rfc4006.txt- | CC stream|| | CCA(Granted-Units)|
../data/rfc/rfc4006.txt- | +|<----------------------------------------|
../data/rfc/rfc4006.txt- | Service Delivery | | |
../data/rfc/rfc4006.txt: |<----------------->| ACR(start,Accounting AVPs) |
../data/rfc/rfc4006.txt- | : |------------------->|+ |
../data/rfc/rfc4006.txt: | : | ACA || Accounting stream |
../data/rfc/rfc4006.txt- | |<-------------------|+ |
../data/rfc/rfc4006.txt- | : | | |
../data/rfc/rfc4006.txt- | : | | |
../data/rfc/rfc4006.txt- | | CCR(Update,Used-Units) |
../data/rfc/rfc4006.txt- | |---------------------------------------->|
--
../data/rfc/rfc4006.txt-RFC 4006 Diameter Credit-Control Application August 2005
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt- The following diagram illustrates the use of
../data/rfc/rfc4006.txt- authorization/authentication messages to perform the first
../data/rfc/rfc4006.txt: interrogation. The parallel accounting stream is not shown in the
../data/rfc/rfc4006.txt- figure.
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt- Service Element Diameter
../data/rfc/rfc4006.txt- End User (CC Client) AAA Server CC Server
../data/rfc/rfc4006.txt- | Service Request | AA Request (CC AVPs) |
--
../data/rfc/rfc4006.txt- locally. The CCFH value received from the home AAA server overrides
../data/rfc/rfc4006.txt- the locally configured value. The CCFH value received from the
../data/rfc/rfc4006.txt- credit-control server in the Credit-Control-Answer message always
../data/rfc/rfc4006.txt- overrides any existing value.
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt: The authorization server MAY include the Accounting-Realtime-Required
../data/rfc/rfc4006.txt: AVP to determine what to do if the sending of accounting records to
../data/rfc/rfc4006.txt: the accounting server has been temporarily prevented, as defined in
../data/rfc/rfc4006.txt- [DIAMBASE]. It is RECOMMENDED that the client complement the
../data/rfc/rfc4006.txt: credit-control failure procedures with backup accounting flow toward
../data/rfc/rfc4006.txt: an accounting server. By using different combinations of
../data/rfc/rfc4006.txt: Accounting-Realtime-Required and Credit-Control-Failure-Handling
../data/rfc/rfc4006.txt- AVPs, different safety levels can be built. For example, by choosing
../data/rfc/rfc4006.txt- a Credit-Control-Failure-Handling AVP equal to CONTINUE for the
../data/rfc/rfc4006.txt: credit-control flow and a Accounting-Realtime-Required AVP equal to
../data/rfc/rfc4006.txt: DELIVER_AND_GRANT for the accounting flow, the service can be granted
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt-Hakala, et al. Standards Track [Page 38]
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt-RFC 4006 Diameter Credit-Control Application August 2005
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt- to the end user even if the connection to the credit-control server
../data/rfc/rfc4006.txt: is down, as long as the accounting server is able to collect the
../data/rfc/rfc4006.txt: accounting information and information exchange is taking place
../data/rfc/rfc4006.txt: between the accounting server and credit-control server.
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt- As the credit-control application is based on real-time bi-
../data/rfc/rfc4006.txt- directional communication between the credit-control client and the
../data/rfc/rfc4006.txt- credit-control server, the usage of alternative destinations and the
../data/rfc/rfc4006.txt- buffering of messages may not be sufficient in the event of
--
../data/rfc/rfc4006.txt- [NASREQ] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
../data/rfc/rfc4006.txt- "Diameter Network Access Server Application", RFC 4005,
../data/rfc/rfc4006.txt- August 2005.
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt- [AAATRANS] Aboba, B. and J. Wood, "Authentication, Authorization and
../data/rfc/rfc4006.txt: Accounting (AAA) Transport Profile", RFC 3539, June 2003.
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt- [URL] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
../data/rfc/rfc4006.txt- Resource Locators (URL)", RFC 1738, December 1994.
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt- [RAD802.1X] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J.
--
../data/rfc/rfc4006.txt- and identification, (release 5), 3GPP TS 23.003 v. 5.8.0,
../data/rfc/rfc4006.txt- 2003-12
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt-15.2. Informative References
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc4006.txt-
../data/rfc/rfc4006.txt- [DIAMMIP] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and
../data/rfc/rfc4006.txt- P. McCann, "Diameter Mobile IPv4 Application", RFC 4004,
../data/rfc/rfc4006.txt- August 2005.
../data/rfc/rfc4006.txt-
--
../data/rfc/rfc5607.txt-Nelson & Weber Standards Track [Page 18]
../data/rfc/rfc5607.txt-
../data/rfc/rfc5607.txt-RFC 5607 RADIUS NAS-Management Authorization July 2009
../data/rfc/rfc5607.txt-
../data/rfc/rfc5607.txt-
../data/rfc/rfc5607.txt: Accounting Messages
../data/rfc/rfc5607.txt- Request Response # Attribute
../data/rfc/rfc5607.txt- ---------------------------------------------------------------------
../data/rfc/rfc5607.txt- 0-1 0 133 Framed-Management-Protocol
../data/rfc/rfc5607.txt- 0-1 0 134 Management-Transport-Protection
../data/rfc/rfc5607.txt- 0-1 0 135 Management-Policy-Id
--
../data/rfc/rfc5607.txt-12. Security Considerations
../data/rfc/rfc5607.txt-
../data/rfc/rfc5607.txt-12.1. General Considerations
../data/rfc/rfc5607.txt-
../data/rfc/rfc5607.txt- This specification describes the use of RADIUS and Diameter for
../data/rfc/rfc5607.txt: purposes of authentication, authorization, and accounting for
../data/rfc/rfc5607.txt- management access to devices within networks. RADIUS threats and
../data/rfc/rfc5607.txt- security issues for this application are described in [RFC3579] and
../data/rfc/rfc5607.txt-
../data/rfc/rfc5607.txt-
../data/rfc/rfc5607.txt-
--
../data/rfc/rfc5607.txt-
../data/rfc/rfc5607.txt- [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
../data/rfc/rfc5607.txt- Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
../data/rfc/rfc5607.txt- Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
../data/rfc/rfc5607.txt-
../data/rfc/rfc5607.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc5607.txt-
../data/rfc/rfc5607.txt- [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
../data/rfc/rfc5607.txt- Architecture for Describing Simple Network Management
../data/rfc/rfc5607.txt- Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
../data/rfc/rfc5607.txt- December 2002.
--
../data/rfc/rfc2200.txt- 2140 - TCP Control Block Interdependence
../data/rfc/rfc2200.txt-
../data/rfc/rfc2200.txt- This is an information document and does not specify any
../data/rfc/rfc2200.txt- level of standard.
../data/rfc/rfc2200.txt-
../data/rfc/rfc2200.txt: 2139 - RADIUS Accounting
../data/rfc/rfc2200.txt-
../data/rfc/rfc2200.txt- This is an information document and does not specify any
../data/rfc/rfc2200.txt- level of standard.
../data/rfc/rfc2200.txt-
../data/rfc/rfc2200.txt- 2138 - Remote Authentication Dial In User Service (RADIUS)
--
../data/rfc/rfc6519.txt- connectivity to customers that are addressed only with an IPv6
../data/rfc/rfc6519.txt- prefix. Dual-Stack Lite requires pre-configuration of the Dual-Stack
../data/rfc/rfc6519.txt- Lite Address Family Transition Router (AFTR) tunnel information on
../data/rfc/rfc6519.txt- the Basic Bridging BroadBand (B4) element. In many networks, the
../data/rfc/rfc6519.txt- customer profile information may be stored in Authentication,
../data/rfc/rfc6519.txt: Authorization, and Accounting (AAA) servers, while client
../data/rfc/rfc6519.txt- configurations are mainly provided through the Dynamic Host
../data/rfc/rfc6519.txt- Configuration Protocol (DHCP). This document specifies a new Remote
../data/rfc/rfc6519.txt- Authentication Dial-In User Service (RADIUS) attribute to carry the
../data/rfc/rfc6519.txt- Dual-Stack Lite AFTR tunnel name; the RADIUS attribute is defined
../data/rfc/rfc6519.txt- based on the equivalent DHCPv6 OPTION_AFTR_NAME option. This RADIUS
--
../data/rfc/rfc6519.txt- DS-Lite client (B4 element) to discover its AFTR name. In order to
../data/rfc/rfc6519.txt- be able to populate such an option, the DHCPv6 server must be
../data/rfc/rfc6519.txt- pre-provisioned with the AFTR name.
../data/rfc/rfc6519.txt-
../data/rfc/rfc6519.txt- In broadband environments, a customer profile may be managed by
../data/rfc/rfc6519.txt: Authentication, Authorization, and Accounting (AAA) servers, together
../data/rfc/rfc6519.txt- with AAA for users. The Remote Authentication Dial-In User Service
../data/rfc/rfc6519.txt- (RADIUS) protocol [RFC2865] is usually used by AAA servers to
../data/rfc/rfc6519.txt- communicate with network elements. [RADIUS-IPv6] describes a typical
../data/rfc/rfc6519.txt- broadband network scenario in which the Network Access Server (NAS)
../data/rfc/rfc6519.txt- acts as the access gateway for the users (hosts or Customer Premises
--
../data/rfc/rfc6519.txt- Upon receiving an AFTR tunnel name different from the currently used
../data/rfc/rfc6519.txt- one, the B4 MUST terminate the current DS-Lite tunnel, and the B4
../data/rfc/rfc6519.txt- MUST establish a new DS-Lite tunnel with the specified AFTR.
../data/rfc/rfc6519.txt-
../data/rfc/rfc6519.txt- The DS-Lite-Tunnel-Name RADIUS attribute MAY be present in
../data/rfc/rfc6519.txt: Accounting-Request records where the Acct-Status-Type is set to
../data/rfc/rfc6519.txt- Start, Stop, or Interim-Update. The DS-Lite-Tunnel-Name RADIUS
../data/rfc/rfc6519.txt- attribute MUST NOT appear more than once in a message.
../data/rfc/rfc6519.txt-
../data/rfc/rfc6519.txt- A summary of the DS-Lite-Tunnel-Name RADIUS attribute format is shown
../data/rfc/rfc6519.txt- below. The fields are transmitted from left to right.
--
../data/rfc/rfc6519.txt-5. Table of Attributes
../data/rfc/rfc6519.txt-
../data/rfc/rfc6519.txt- The following tables provide a guide to which attributes may be found
../data/rfc/rfc6519.txt- in which kinds of packets, and in what quantity.
../data/rfc/rfc6519.txt-
../data/rfc/rfc6519.txt: Access- Access- Access- Challenge Accounting # Attribute
../data/rfc/rfc6519.txt- Request Accept Reject Request
../data/rfc/rfc6519.txt- 0-1 0-1 0 0 0-1 144 DS-Lite-Tunnel-Name
../data/rfc/rfc6519.txt-
../data/rfc/rfc6519.txt- CoA-Request CoA-ACK CoA-NACK # Attribute
../data/rfc/rfc6519.txt- 0-1 0 0 144 DS-Lite-Tunnel-Name
--
../data/rfc/rfc696.txt-
../data/rfc/rfc696.txt- FACILITIES - 16 bits
../data/rfc/rfc696.txt-
../data/rfc/rfc696.txt- These bits have not yet been specifically allocated. Some will no
../data/rfc/rfc696.txt- doubt be for international services (e.g., tracing at gateways
../data/rfc/rfc696.txt: between networks, accounting, class of service). It was the
../data/rfc/rfc696.txt- feeling of WG 6.1 members that some of these bits (e.g., 8) might
../data/rfc/rfc696.txt- be allocated to the originating network (or destination network)
../data/rfc/rfc696.txt- for its own use.
../data/rfc/rfc696.txt-
../data/rfc/rfc696.txt-
--
../data/rfc/rfc2212.txt- obey the rule that over all time periods, the amount of data sent
../data/rfc/rfc2212.txt- cannot exceed M+min[pT, rT+b-M], where r and b are the token bucket
../data/rfc/rfc2212.txt- parameters, M is the maximum datagram size, and T is the length of
../data/rfc/rfc2212.txt- the time period (note that when p is infinite this reduces to the
../data/rfc/rfc2212.txt- standard token bucket requirement). For the purposes of this
../data/rfc/rfc2212.txt: accounting, links MUST count datagrams which are smaller than the
../data/rfc/rfc2212.txt- minimum policing unit to be of size m. Datagrams which arrive at an
../data/rfc/rfc2212.txt- element and cause a violation of the the M+min[pT, rT+b-M] bound are
../data/rfc/rfc2212.txt- considered non-conformant.
../data/rfc/rfc2212.txt-
../data/rfc/rfc2212.txt- At the edge of the network, traffic is policed to ensure it conforms
--
../data/rfc/rfc5592.txt- maintained by IANA). The use of the "none" authentication method is
../data/rfc/rfc5592.txt- NOT RECOMMENDED, as described in this document's Security
../data/rfc/rfc5592.txt- Considerations. Local accounts may be supported through the use of
../data/rfc/rfc5592.txt- the publickey, hostbased, or password methods. The password method
../data/rfc/rfc5592.txt- allows for integration with a deployed password infrastructure, such
../data/rfc/rfc5592.txt: as Authentication, Authorization, and Accounting (AAA) servers using
../data/rfc/rfc5592.txt- the RADIUS protocol [RFC2865]. The SSH Transport Model SHOULD be
../data/rfc/rfc5592.txt- able to take advantage of future-defined ssh-userauth methods, such
../data/rfc/rfc5592.txt- as those that might make use of X.509 certificate credentials.
../data/rfc/rfc5592.txt-
../data/rfc/rfc5592.txt- It is desirable to use mechanisms that could unify the approach for
--
../data/rfc/rfc5015.txt-RFC 5015 Bidirectional PIM October 2007
../data/rfc/rfc5015.txt-
../data/rfc/rfc5015.txt-
../data/rfc/rfc5015.txt- specific state. Upstream forwarding can be performed using only RPA
../data/rfc/rfc5015.txt- specific state. An implementation may decide to maintain group state
../data/rfc/rfc5015.txt: for source-only branches for accounting or performance reasons.
../data/rfc/rfc5015.txt- However, doing so requires data-driven events (to discover the groups
../data/rfc/rfc5015.txt- with active sources), thus sacrificing one of the main benefits of
../data/rfc/rfc5015.txt- BIDIR-PIM.
../data/rfc/rfc5015.txt-
../data/rfc/rfc5015.txt-3.3.3. Directly Connected Sources
--
../data/rfc/rfc5559.txt- 5. Operations and Management ......................................25
../data/rfc/rfc5559.txt- 5.1. Fault Operations and Management ...........................25
../data/rfc/rfc5559.txt- 5.2. Configuration Operations and Management ...................26
../data/rfc/rfc5559.txt- 5.2.1. System Options .....................................27
../data/rfc/rfc5559.txt- 5.2.2. Parameters .........................................28
../data/rfc/rfc5559.txt: 5.3. Accounting Operations and Management ......................30
../data/rfc/rfc5559.txt- 5.4. Performance and Provisioning Operations and Management ....30
../data/rfc/rfc5559.txt- 5.5. Security Operations and Management ........................31
../data/rfc/rfc5559.txt- 6. Applicability of PCN ...........................................32
../data/rfc/rfc5559.txt- 6.1. Benefits ..................................................32
../data/rfc/rfc5559.txt- 6.2. Deployment Scenarios ......................................33
--
../data/rfc/rfc5559.txt- signalling protocol.
../data/rfc/rfc5559.txt-
../data/rfc/rfc5559.txt-5. Operations and Management
../data/rfc/rfc5559.txt-
../data/rfc/rfc5559.txt- This section considers operations and management issues, under the
../data/rfc/rfc5559.txt: FCAPS headings: Faults, Configuration, Accounting, Performance, and
../data/rfc/rfc5559.txt- Security. Provisioning is discussed with performance.
../data/rfc/rfc5559.txt-
../data/rfc/rfc5559.txt-5.1. Fault Operations and Management
../data/rfc/rfc5559.txt-
../data/rfc/rfc5559.txt- Fault Operations and Management is about preventing faults, telling
--
../data/rfc/rfc5559.txt-Eardley Informational [Page 29]
../data/rfc/rfc5559.txt-
../data/rfc/rfc5559.txt-RFC 5559 PCN Architecture June 2009
../data/rfc/rfc5559.txt-
../data/rfc/rfc5559.txt-
../data/rfc/rfc5559.txt:5.3. Accounting Operations and Management
../data/rfc/rfc5559.txt-
../data/rfc/rfc5559.txt: Accounting is only done at trust boundaries so it is out of scope of
../data/rfc/rfc5559.txt- this document, which is confined to intra-domain issues. Use of PCN
../data/rfc/rfc5559.txt- internal to a domain makes no difference to the flow signalling
../data/rfc/rfc5559.txt- events crossing trust boundaries outside the PCN-domain, which are
../data/rfc/rfc5559.txt: typically used for accounting.
../data/rfc/rfc5559.txt-
../data/rfc/rfc5559.txt-5.4. Performance and Provisioning Operations and Management
../data/rfc/rfc5559.txt-
../data/rfc/rfc5559.txt- Monitoring of performance factors measurable from *outside* the PCN-
../data/rfc/rfc5559.txt- domain will be no different with PCN than with any other packet-
--
../data/rfc/rfc808.txt- personal computer will not be available to handle incoming mail
../data/rfc/rfc808.txt- all the time. Probably, personal computer users will have their
../data/rfc/rfc808.txt- mailboxes on some big brother computer (which may be dedicated to
../data/rfc/rfc808.txt- mailbox service, or be a general purpose host) and poll for their
../data/rfc/rfc808.txt- mail when they want to read it. There were some concerns raised
../data/rfc/rfc808.txt: about accountability and accounting.
../data/rfc/rfc808.txt-
../data/rfc/rfc808.txt- 6. Bob Thomas talked about the ideas for routing mail between
../data/rfc/rfc808.txt- regular mailboxes on ARPANET Hosts and mailboxes of NSW users.
../data/rfc/rfc808.txt-
../data/rfc/rfc808.txt- The main point of interest is that an NSW user is not a user of a
--
../data/rfc/rfc2708.txt-
../data/rfc/rfc2708.txt-MIB attribute | DPA job attribute |IPP Data type
../data/rfc/rfc2708.txt----------------------------+------------------------------+-------------
../data/rfc/rfc2708.txt-jobStateReasonsN(N=2, 3, 4)| job-state-reasons (note 2) | Integer
../data/rfc/rfc2708.txt-jobCodedCharSet | (note 1) | Octet String
../data/rfc/rfc2708.txt:jobAccountName | accounting-information | Octet String
../data/rfc/rfc2708.txt-jobName | job-name | Octet String
../data/rfc/rfc2708.txt-deviceNameRequested | printer-name-requested | Octet String
../data/rfc/rfc2708.txt-physicalDevice | printers-assigned | Octet String
../data/rfc/rfc2708.txt-numberOfDocuments | number-of-documents | Integer
../data/rfc/rfc2708.txt-fileName | file-name | Octet String
--
../data/rfc/rfc4005.txt- Copyright (C) The Internet Society (2005).
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-Abstract
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- This document describes the Diameter protocol application used for
../data/rfc/rfc4005.txt: Authentication, Authorization, and Accounting (AAA) services in the
../data/rfc/rfc4005.txt- Network Access Server (NAS) environment. When combined with the
../data/rfc/rfc4005.txt- Diameter Base protocol, Transport Profile, and Extensible
../data/rfc/rfc4005.txt- Authentication Protocol specifications, this application
../data/rfc/rfc4005.txt- specification satisfies typical network access services requirements.
../data/rfc/rfc4005.txt-
--
../data/rfc/rfc4005.txt- 3.4. Re-Auth-Answer (RAA) Command . . . . . . . . . . . . . . 14
../data/rfc/rfc4005.txt- 3.5. Session-Termination-Request (STR) Command . . . . . . . 15
../data/rfc/rfc4005.txt- 3.6. Session-Termination-Answer (STA) Command . . . . . . . . 15
../data/rfc/rfc4005.txt- 3.7. Abort-Session-Request (ASR) Command . . . . . . . . . . 16
../data/rfc/rfc4005.txt- 3.8. Abort-Session-Answer (ASA) Command . . . . . . . . . . . 17
../data/rfc/rfc4005.txt: 3.9. Accounting-Request (ACR) Command . . . . . . . . . . . . 17
../data/rfc/rfc4005.txt: 3.10. Accounting-Answer (ACA) Command. . . . . . . . . . . . . 19
../data/rfc/rfc4005.txt- 4. NAS Session AVPs . . . . . . . . . . . . . . . . . . . . . . . 20
../data/rfc/rfc4005.txt- 4.1. Call and Session Information . . . . . . . . . . . . . . 21
../data/rfc/rfc4005.txt- 4.2. NAS-Port AVP . . . . . . . . . . . . . . . . . . . . . . 22
../data/rfc/rfc4005.txt- 4.3. NAS-Port-Id AVP . . . . . . . . . . . . . . . . . . . . 22
../data/rfc/rfc4005.txt- 4.4. NAS-Port-Type AVP . . . . . . . . . . . . . . . . . . . 22
--
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- 7.8. Tunnel-Assignment-Id AVP . . . . . . . . . . . . . . . . 48
../data/rfc/rfc4005.txt- 7.9. Tunnel-Preference AVP . . . . . . . . . . . . . . . . . 49
../data/rfc/rfc4005.txt- 7.10. Tunnel-Client-Auth-Id AVP. . . . . . . . . . . . . . . . 50
../data/rfc/rfc4005.txt- 7.11. Tunnel-Server-Auth-Id AVP. . . . . . . . . . . . . . . . 50
../data/rfc/rfc4005.txt: 8. NAS Accounting . . . . . . . . . . . . . . . . . . . . . . . . 50
../data/rfc/rfc4005.txt: 8.1. Accounting-Input-Octets AVP . . . . . . . . . . . . . . 51
../data/rfc/rfc4005.txt: 8.2. Accounting-Output-Octets AVP . . . . . . . . . . . . . . 52
../data/rfc/rfc4005.txt: 8.3. Accounting-Input-Packets AVP . . . . . . . . . . . . . . 52
../data/rfc/rfc4005.txt: 8.4. Accounting-Output-Packets AVP . . . . . . . . . . . . . 52
../data/rfc/rfc4005.txt- 8.5. Acct-Session-Time AVP . . . . . . . . . . . . . . . . . 52
../data/rfc/rfc4005.txt- 8.6. Acct-Authentic AVP . . . . . . . . . . . . . . . . . . . 52
../data/rfc/rfc4005.txt: 8.7. Accounting-Auth-Method AVP . . . . . . . . . . . . . . . 53
../data/rfc/rfc4005.txt- 8.8. Acct-Delay-Time . . . . . . . . . . . . . . . . . . . . 53
../data/rfc/rfc4005.txt- 8.9. Acct-Link-Count . . . . . . . . . . . . . . . . . . . . 54
../data/rfc/rfc4005.txt- 8.10. Acct-Tunnel-Connection AVP . . . . . . . . . . . . . . . 54
../data/rfc/rfc4005.txt- 8.11. Acct-Tunnel-Packets-Lost AVP . . . . . . . . . . . . . . 55
../data/rfc/rfc4005.txt- 9. RADIUS/Diameter Protocol Interactions . . . . . . . . . . . . 55
--
../data/rfc/rfc4005.txt- RADIUS VSA . . . . . . . . . . . . . . . . . . . 70
../data/rfc/rfc4005.txt- 9.6.2. Forwarding a RADIUS VSA as a Diameter Vendor
../data/rfc/rfc4005.txt- Specific AVP . . . . . . . . . . . . . . . . . . 70
../data/rfc/rfc4005.txt- 10. AVP Occurrence Tables. . . . . . . . . . . . . . . . . . . . . 71
../data/rfc/rfc4005.txt- 10.1. AA-Request/Answer AVP Table. . . . . . . . . . . . . . . 71
../data/rfc/rfc4005.txt: 10.2. Accounting AVP Tables. . . . . . . . . . . . . . . . . . 73
../data/rfc/rfc4005.txt: 10.2.1. Accounting Framed Access AVP Table. . . . . . . 74
../data/rfc/rfc4005.txt: 10.2.2. Accounting Non-Framed Access AVP Table. . . . . 76
../data/rfc/rfc4005.txt- 11. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 77
../data/rfc/rfc4005.txt- 11.1. Command Codes. . . . . . . . . . . . . . . . . . . . . . 77
../data/rfc/rfc4005.txt- 11.2. AVP Codes. . . . . . . . . . . . . . . . . . . . . . . . 78
../data/rfc/rfc4005.txt- 11.3. Application Identifier . . . . . . . . . . . . . . . . . 78
../data/rfc/rfc4005.txt- 11.4. CHAP-Algorithm AVP Values. . . . . . . . . . . . . . . . 78
../data/rfc/rfc4005.txt: 11.5. Accounting-Auth-Method AVP Values. . . . . . . . . . . . 78
../data/rfc/rfc4005.txt- 11.6. Origin-AAA-Protocol AVP Values . . . . . . . . . . . . . 78
../data/rfc/rfc4005.txt- 12. Security Considerations. . . . . . . . . . . . . . . . . . . . 78
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-
--
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- First, this document describes the operation of a Diameter NAS
../data/rfc/rfc4005.txt- application. Then it defines the Diameter message Command-Codes.
../data/rfc/rfc4005.txt- The following sections list the AVPs used in these messages, grouped
../data/rfc/rfc4005.txt- by common usage. These are session identification, authentication,
../data/rfc/rfc4005.txt: authorization, tunneling, and accounting. The authorization AVPs are
../data/rfc/rfc4005.txt- further broken down by service type. Interaction and backward
../data/rfc/rfc4005.txt- compatibility issues with RADIUS are discussed in later sections.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-1.1. Terminology
../data/rfc/rfc4005.txt-
--
../data/rfc/rfc4005.txt- When the authentication or authorization exchange completes
../data/rfc/rfc4005.txt- successfully, the NAS application SHOULD start a session context. If
../data/rfc/rfc4005.txt- the Result-Code of DIAMETER_MULTI_ROUND_AUTH is returned, the
../data/rfc/rfc4005.txt- exchange continues until a success or error is returned.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt: If accounting is active, the application MUST also send an Accounting
../data/rfc/rfc4005.txt: message [BASE]. An Accounting-Record-Type of START_RECORD is sent
../data/rfc/rfc4005.txt- for a new session. If a session fails to start, the EVENT_RECORD
../data/rfc/rfc4005.txt- message is sent with the reason for the failure described.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt: Note that the return of an unsupportable Accounting-Realtime-Required
../data/rfc/rfc4005.txt- value [BASE] would result in a failure to establish the session.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-2.2. Diameter Session Reauthentication or Reauthorization
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- The Diameter Base protocol allows users to be periodically
--
../data/rfc/rfc4005.txt- indicated by the Re-Auth-Request-Type value. This will cause the NAS
../data/rfc/rfc4005.txt- to send a new AAR message using the existing Session-Id. The server
../data/rfc/rfc4005.txt- will respond with an AAA message to specify the new service
../data/rfc/rfc4005.txt- parameters.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt: If accounting is active, every change of authentication or
../data/rfc/rfc4005.txt: authorization SHOULD generate an accounting message. If the NAS
../data/rfc/rfc4005.txt- service is a continuation of the prior user context, then an
../data/rfc/rfc4005.txt: Accounting-Record-Type of INTERIM_RECORD indicating the new session
../data/rfc/rfc4005.txt- attributes and cumulative status would be appropriate. If a new user
../data/rfc/rfc4005.txt- or a significant change in authorization is detected by the NAS, then
../data/rfc/rfc4005.txt- the service may send two messages of the types STOP_RECORD and
../data/rfc/rfc4005.txt: START_RECORD. Accounting may change the subsession identifiers
../data/rfc/rfc4005.txt- (Acct-Session-ID, or Acct-Sub-Session-Id) to indicate such sub-
../data/rfc/rfc4005.txt- sessions. A service may also use a different Session-Id value for
../data/rfc/rfc4005.txt: accounting (see [BASE] section 9.6).
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- However, the Diameter Session-ID AVP value used for the initial
../data/rfc/rfc4005.txt- authorization exchange MUST be used to generate an STR message when
../data/rfc/rfc4005.txt- the session context is terminated.
../data/rfc/rfc4005.txt-
--
../data/rfc/rfc4005.txt-Calhoun, et al. Standards Track [Page 8]
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-RFC 4005 Diameter Network Access Server Application August 2005
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt: If accounting is active, an Accounting STOP_RECORD message [BASE]
../data/rfc/rfc4005.txt- MUST be sent upon termination of the session context.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- More information on Diameter Session Termination is included in
../data/rfc/rfc4005.txt- [BASE] sections 8.4 and 8.5.
../data/rfc/rfc4005.txt-
--
../data/rfc/rfc4005.txt- Re-Auth-Answer RAA 258 3.4
../data/rfc/rfc4005.txt- Session-Termination-Request STR 275 3.5
../data/rfc/rfc4005.txt- Session-Termination-Answer STA 275 3.6
../data/rfc/rfc4005.txt- Abort-Session-Request ASR 274 3.7
../data/rfc/rfc4005.txt- Abort-Session-Answer ASA 274 3.8
../data/rfc/rfc4005.txt: Accounting-Request ACR 271 3.9
../data/rfc/rfc4005.txt: Accounting-Answer ACA 271 3.10
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-3.1. AA-Request (AAR) Command
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- The AA-Request (AAR), which is indicated by setting the Command-Code
../data/rfc/rfc4005.txt- field to 265 and the 'R' bit in the Command Flags field, is used to
--
../data/rfc/rfc4005.txt- [ Redirected-Host-Usage ]
../data/rfc/rfc4005.txt- [ Redirected-Max-Cache-Time ]
../data/rfc/rfc4005.txt- * [ Proxy-Info ]
../data/rfc/rfc4005.txt- * [ AVP ]
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt:3.9. Accounting-Request (ACR) Command
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- The ACR message [BASE] is sent by the NAS to report its session
../data/rfc/rfc4005.txt- information to a target server downstream.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- Either of Acct-Application-Id or Vendor-Specific-Application-Id AVPs
../data/rfc/rfc4005.txt- MUST be present. If the Vendor-Specific-Application-Id grouped AVP
../data/rfc/rfc4005.txt- is present, it must have an Acct-Application-Id inside.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- The AVPs listed in the Base MUST be assumed to be present, as
../data/rfc/rfc4005.txt: appropriate. NAS service-specific accounting AVPs SHOULD be present
../data/rfc/rfc4005.txt- as described in section 8 and the rest of this specification.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-
--
../data/rfc/rfc4005.txt- <AC-Request> ::= < Diameter Header: 271, REQ, PXY >
../data/rfc/rfc4005.txt- < Session-Id >
../data/rfc/rfc4005.txt- { Origin-Host }
../data/rfc/rfc4005.txt- { Origin-Realm }
../data/rfc/rfc4005.txt- { Destination-Realm }
../data/rfc/rfc4005.txt: { Accounting-Record-Type }
../data/rfc/rfc4005.txt: { Accounting-Record-Number }
../data/rfc/rfc4005.txt- [ Acct-Application-Id ]
../data/rfc/rfc4005.txt- [ Vendor-Specific-Application-Id ]
../data/rfc/rfc4005.txt- [ User-Name ]
../data/rfc/rfc4005.txt: [ Accounting-Sub-Session-Id ]
../data/rfc/rfc4005.txt- [ Acct-Session-Id ]
../data/rfc/rfc4005.txt- [ Acct-Multi-Session-Id ]
../data/rfc/rfc4005.txt- [ Origin-AAA-Protocol ]
../data/rfc/rfc4005.txt- [ Origin-State-Id ]
../data/rfc/rfc4005.txt- [ Destination-Host ]
--
../data/rfc/rfc4005.txt- [ NAS-Port-Id ]
../data/rfc/rfc4005.txt- [ NAS-Port-Type ]
../data/rfc/rfc4005.txt- * [ Class ]
../data/rfc/rfc4005.txt- [ Service-Type ]
../data/rfc/rfc4005.txt- [ Termination-Cause ]
../data/rfc/rfc4005.txt: [ Accounting-Input-Octets ]
../data/rfc/rfc4005.txt: [ Accounting-Input-Packets ]
../data/rfc/rfc4005.txt: [ Accounting-Output-Octets ]
../data/rfc/rfc4005.txt: [ Accounting-Output-Packets ]
../data/rfc/rfc4005.txt- [ Acct-Authentic ]
../data/rfc/rfc4005.txt: [ Accounting-Auth-Method ]
../data/rfc/rfc4005.txt- [ Acct-Link-Count ]
../data/rfc/rfc4005.txt- [ Acct-Session-Time ]
../data/rfc/rfc4005.txt- [ Acct-Tunnel-Connection ]
../data/rfc/rfc4005.txt- [ Acct-Tunnel-Packets-Lost ]
../data/rfc/rfc4005.txt- [ Callback-Id ]
--
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-RFC 4005 Diameter Network Access Server Application August 2005
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- [ Port-Limit ]
../data/rfc/rfc4005.txt: [ Accounting-Realtime-Required ]
../data/rfc/rfc4005.txt- [ Acct-Interim-Interval ]
../data/rfc/rfc4005.txt- * [ Filter-Id ]
../data/rfc/rfc4005.txt- * [ NAS-Filter-Rule ]
../data/rfc/rfc4005.txt- * [ Qos-Filter-Rule ]
../data/rfc/rfc4005.txt- [ Framed-AppleTalk-Link ]
--
../data/rfc/rfc4005.txt- * [ Tunneling ]
../data/rfc/rfc4005.txt- * [ Proxy-Info ]
../data/rfc/rfc4005.txt- * [ Route-Record ]
../data/rfc/rfc4005.txt- * [ AVP ]
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt:3.10. Accounting-Answer (ACA) Command
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt: The ACA message [BASE] is used to acknowledge an Accounting-Request
../data/rfc/rfc4005.txt: command. The Accounting-Answer command contains the same Session-Id
../data/rfc/rfc4005.txt: as the Request. If the Accounting-Request was protected by end-to-
../data/rfc/rfc4005.txt- end security, then the corresponding ACA message MUST be protected as
../data/rfc/rfc4005.txt- well.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- Only the target Diameter Server or home Diameter Server SHOULD
../data/rfc/rfc4005.txt: respond with the Accounting-Answer command.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- Either Acct-Application-Id or Vendor-Specific-Application-Id AVPs
../data/rfc/rfc4005.txt- MUST be present, as it was in the request.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-
--
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-RFC 4005 Diameter Network Access Server Application August 2005
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- The AVPs listed in the Base MUST be assumed to be present, as
../data/rfc/rfc4005.txt: appropriate. NAS service-specific accounting AVPs SHOULD be present
../data/rfc/rfc4005.txt- as described in section 8 and the rest of this specification.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- Message Format
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- <AC-Answer> ::= < Diameter Header: 271, PXY >
../data/rfc/rfc4005.txt- < Session-Id >
../data/rfc/rfc4005.txt- { Result-Code }
../data/rfc/rfc4005.txt- { Origin-Host }
../data/rfc/rfc4005.txt- { Origin-Realm }
../data/rfc/rfc4005.txt: { Accounting-Record-Type }
../data/rfc/rfc4005.txt: { Accounting-Record-Number }
../data/rfc/rfc4005.txt- [ Acct-Application-Id ]
../data/rfc/rfc4005.txt- [ Vendor-Specific-Application-Id ]
../data/rfc/rfc4005.txt- [ User-Name ]
../data/rfc/rfc4005.txt: [ Accounting-Sub-Session-Id ]
../data/rfc/rfc4005.txt- [ Acct-Session-Id ]
../data/rfc/rfc4005.txt- [ Acct-Multi-Session-Id ]
../data/rfc/rfc4005.txt- [ Event-Timestamp ]
../data/rfc/rfc4005.txt- [ Error-Message ]
../data/rfc/rfc4005.txt- [ Error-Reporting-Host ]
--
../data/rfc/rfc4005.txt- [ NAS-Port ]
../data/rfc/rfc4005.txt- [ NAS-Port-Id ]
../data/rfc/rfc4005.txt- [ NAS-Port-Type ]
../data/rfc/rfc4005.txt- [ Service-Type ]
../data/rfc/rfc4005.txt- [ Termination-Cause ]
../data/rfc/rfc4005.txt: [ Accounting-Realtime-Required ]
../data/rfc/rfc4005.txt- [ Acct-Interim-Interval ]
../data/rfc/rfc4005.txt- * [ Class ]
../data/rfc/rfc4005.txt- * [ Proxy-Info ]
../data/rfc/rfc4005.txt- * [ Route-Record ]
../data/rfc/rfc4005.txt- * [ AVP ]
--
../data/rfc/rfc4005.txt- optional information.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- For example: "28800 V42BIS/LAPM" or "52000/31200 V90"
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- More than one Connect-Info attribute may be present in an
../data/rfc/rfc4005.txt: Accounting-Request packet to accommodate expected efforts by the ITU
../data/rfc/rfc4005.txt- to have modems report more connection information in a standard
../data/rfc/rfc4005.txt- format that might exceed 252 octets.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- If sent in the ACR STOP, this attribute may summarize statistics
../data/rfc/rfc4005.txt- relating to session quality. For example, in IEEE 802.11, the
--
../data/rfc/rfc4005.txt- initiator) or in use (in the case of a tunnel terminator). It MAY be
../data/rfc/rfc4005.txt- used in an authorization request as a hint to the server that a
../data/rfc/rfc4005.txt- specific tunnel type is desired, but the server is not required to
../data/rfc/rfc4005.txt- honor the hint in the corresponding response.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt: The Tunnel-Type AVP SHOULD also be included in Accounting-Request
../data/rfc/rfc4005.txt- messages.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- A tunnel initiator is not required to implement any of these tunnel
../data/rfc/rfc4005.txt- types. If a tunnel initiator receives a response that contains only
../data/rfc/rfc4005.txt- unknown or unsupported Tunnel-Types, the tunnel initiator MUST behave
--
../data/rfc/rfc4005.txt- and contains the address of the initiator end of the tunnel. It MAY
../data/rfc/rfc4005.txt- be used in an authorization request as a hint to the server that a
../data/rfc/rfc4005.txt- specific endpoint is desired, but the server is not required to honor
../data/rfc/rfc4005.txt- the hint in the corresponding response.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt: This AVP SHOULD be included in the corresponding Accounting-Request
../data/rfc/rfc4005.txt- messages, in which case it indicates the address from which the
../data/rfc/rfc4005.txt- tunnel was initiated. This AVP, along with the Tunnel-Server-
../data/rfc/rfc4005.txt- Endpoint and Session-Id AVP [BASE], MAY be used to provide a globally
../data/rfc/rfc4005.txt: unique means to identify a tunnel for accounting and auditing
../data/rfc/rfc4005.txt- purposes.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- If Tunnel-Medium-Type is IPv4 (1), then this string is either the
../data/rfc/rfc4005.txt- fully qualified domain name (FQDN) of the tunnel client machine, or a
../data/rfc/rfc4005.txt-
--
../data/rfc/rfc4005.txt- and contains the address of the server end of the tunnel. It MAY be
../data/rfc/rfc4005.txt- used in an authorization request as a hint to the server that a
../data/rfc/rfc4005.txt- specific endpoint is desired, but the server is not required to honor
../data/rfc/rfc4005.txt- the hint in the corresponding response.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt: This AVP SHOULD be included in the corresponding Accounting-Request
../data/rfc/rfc4005.txt- messages, in which case it indicates the address from which the
../data/rfc/rfc4005.txt- tunnel was initiated. This AVP, along with the Tunnel-Client-
../data/rfc/rfc4005.txt- Endpoint and Session-Id AVP [BASE], MAY be used to provide a globally
../data/rfc/rfc4005.txt: unique means to identify a tunnel for accounting and auditing
../data/rfc/rfc4005.txt- purposes.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- If Tunnel-Medium-Type is IPv4 (1), then this string is either the
../data/rfc/rfc4005.txt- fully qualified domain name (FQDN) of the tunnel server machine, or a
../data/rfc/rfc4005.txt- "dotted-decimal" IP address. Implementations MUST support the
--
../data/rfc/rfc4005.txt- authorization response if this tunnel session is to be treated as
../data/rfc/rfc4005.txt- belonging to a particular private group. Private groups may be used
../data/rfc/rfc4005.txt- to associate a tunneled session with a particular group of users.
../data/rfc/rfc4005.txt- For example, it MAY be used to facilitate routing of unregistered IP
../data/rfc/rfc4005.txt- addresses through a particular interface. This AVP SHOULD be
../data/rfc/rfc4005.txt: included in the Accounting-Request messages that pertain to the
../data/rfc/rfc4005.txt- tunneled session.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-7.8. Tunnel-Assignment-Id AVP
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- The Tunnel-Assignment-Id AVP (AVP Code 82) is of type OctetString and
--
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- This attribute MAY be included in authorization responses. The
../data/rfc/rfc4005.txt- tunnel initiator receiving this attribute MAY choose to ignore it and
../data/rfc/rfc4005.txt- to assign the session to an arbitrary multiplexed or non-multiplexed
../data/rfc/rfc4005.txt- tunnel between the desired endpoints. This AVP SHOULD also be
../data/rfc/rfc4005.txt: included in the Accounting-Request messages pertaining to the
../data/rfc/rfc4005.txt- tunneled session.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- If a tunnel initiator supports the Tunnel-Assignment-Id AVP, then it
../data/rfc/rfc4005.txt- should assign a session to a tunnel in the following manner:
../data/rfc/rfc4005.txt-
--
../data/rfc/rfc4005.txt- authentication phase of tunnel establishment. It MAY be used in an
../data/rfc/rfc4005.txt- authorization request as a hint to the server that a specific
../data/rfc/rfc4005.txt- preference is desired, but the server is not required to honor the
../data/rfc/rfc4005.txt- hint in the corresponding response. This AVP MUST be present in the
../data/rfc/rfc4005.txt- authorization response if an authentication name other than the
../data/rfc/rfc4005.txt: default is desired. This AVP SHOULD be included in the Accounting-
../data/rfc/rfc4005.txt- Request messages pertaining to the tunneled session.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-7.11. Tunnel-Server-Auth-Id AVP
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- The Tunnel-Server-Auth-Id AVP (AVP Code 91) is of type UTF8String and
--
../data/rfc/rfc4005.txt- authentication phase of tunnel establishment. It MAY be used in an
../data/rfc/rfc4005.txt- authorization request as a hint to the server that a specific
../data/rfc/rfc4005.txt- preference is desired, but the server is not required to honor the
../data/rfc/rfc4005.txt- hint in the corresponding response. This AVP MUST be present in the
../data/rfc/rfc4005.txt- authorization response if an authentication name other than the
../data/rfc/rfc4005.txt: default is desired. This AVP SHOULD be included in the Accounting-
../data/rfc/rfc4005.txt- Request messages pertaining to the tunneled session.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt:8. NAS Accounting
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt: Applications implementing this specification use Diameter Accounting,
../data/rfc/rfc4005.txt- as defined in [BASE], and the AVPs in the following section.
../data/rfc/rfc4005.txt- Service-specific AVP usage is defined in the tables in section 10.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt: If accounting is active, Accounting Request (ACR) messages SHOULD be
../data/rfc/rfc4005.txt- sent after the completion of any Authentication or Authorization
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-Calhoun, et al. Standards Track [Page 50]
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-RFC 4005 Diameter Network Access Server Application August 2005
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt: transaction and at the end of a Session. The Accounting-Record-Type
../data/rfc/rfc4005.txt- value indicates the type of event. All other AVPs identify the
../data/rfc/rfc4005.txt- session and provide additional information relevant to the event.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- The successful completion of the first Authentication or
../data/rfc/rfc4005.txt- Authorization transaction SHOULD cause a START_RECORD to be sent. If
--
../data/rfc/rfc4005.txt- | AVP Flag rules |
../data/rfc/rfc4005.txt- |----+-----+----+-----|----+
../data/rfc/rfc4005.txt- AVP Section | | |SHLD| MUST| |
../data/rfc/rfc4005.txt- Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr|
../data/rfc/rfc4005.txt- -----------------------------------------|----+-----+----+-----|----|
../data/rfc/rfc4005.txt: Accounting- 363 8.1 Unsigned64 | M | P | | V | Y |
../data/rfc/rfc4005.txt- Input-Octets | | | | | |
../data/rfc/rfc4005.txt: Accounting- 364 8.2 Unsigned64 | M | P | | V | Y |
../data/rfc/rfc4005.txt- Output-Octets | | | | | |
../data/rfc/rfc4005.txt: Accounting- 365 8.3 Unsigned64 | M | P | | V | Y |
../data/rfc/rfc4005.txt- Input-Packets | | | | | |
../data/rfc/rfc4005.txt: Accounting- 366 8.4 Unsigned64 | M | P | | V | Y |
../data/rfc/rfc4005.txt- Output-Packets | | | | | |
../data/rfc/rfc4005.txt- Acct-Session-Time 46 8.5 Unsigned32 | M | P | | V | Y |
../data/rfc/rfc4005.txt- Acct-Authentic 45 8.6 Enumerated | M | P | | V | Y |
../data/rfc/rfc4005.txt- Acounting-Auth- 406 8.7 Enumerated | M | P | | V | Y |
../data/rfc/rfc4005.txt- Method | | | | | |
--
../data/rfc/rfc4005.txt- Connection | | | | | |
../data/rfc/rfc4005.txt- Acct-Tunnel- 86 8.11 Unsigned32 | M | P | | V | Y |
../data/rfc/rfc4005.txt- Packets-Lost | | | | | |
../data/rfc/rfc4005.txt- -----------------------------------------|----+-----+----+-----|----|
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt:8.1. Accounting-Input-Octets AVP
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt: The Accounting-Input-Octets AVP (AVP Code 363) is of type Unsigned64
../data/rfc/rfc4005.txt- and contains the number of octets received from the user.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-
--
../data/rfc/rfc4005.txt-RFC 4005 Diameter Network Access Server Application August 2005
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- For NAS usage, this AVP indicates how many octets have been received
../data/rfc/rfc4005.txt- from the port in the course of this session. It can only be present
../data/rfc/rfc4005.txt: in ACR messages with an Accounting-Record-Type of INTERIM_RECORD or
../data/rfc/rfc4005.txt- STOP_RECORD.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt:8.2. Accounting-Output-Octets AVP
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt: The Accounting-Output-Octets AVP (AVP Code 364) is of type Unsigned64
../data/rfc/rfc4005.txt- and contains the number of octets sent to the user.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- For NAS usage, this AVP indicates how many octets have been sent to
../data/rfc/rfc4005.txt- the port in the course of this session. It can only be present in
../data/rfc/rfc4005.txt: ACR messages with an Accounting-Record-Type of INTERIM_RECORD or
../data/rfc/rfc4005.txt- STOP_RECORD.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt:8.3. Accounting-Input-Packets AVP
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt: The Accounting-Input-Packets (AVP Code 365) is of type Unsigned64 and
../data/rfc/rfc4005.txt- contains the number of packets received from the user.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- For NAS usage, this AVP indicates how many packets have been received
../data/rfc/rfc4005.txt- from the port over the course of a session being provided to a Framed
../data/rfc/rfc4005.txt: User. It can only be present in ACR messages with an Accounting-
../data/rfc/rfc4005.txt- Record-Type of INTERIM_RECORD or STOP_RECORD.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt:8.4. Accounting-Output-Packets AVP
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt: The Accounting-Output-Packets (AVP Code 366) is of type Unsigned64
../data/rfc/rfc4005.txt- and contains the number of IP packets sent to the user.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- For NAS usage, this AVP indicates how many packets have been sent to
../data/rfc/rfc4005.txt- the port over the course of a session being provided to a Framed
../data/rfc/rfc4005.txt: User. It can only be present in ACR messages with an Accounting-
../data/rfc/rfc4005.txt- Record-Type of INTERIM_RECORD or STOP_RECORD.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-8.5. Acct-Session-Time AVP
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- The Acct-Session-Time AVP (AVP Code 46) is of type Unsigned32 and
../data/rfc/rfc4005.txt- indicates the length of the current session in seconds. It can only
../data/rfc/rfc4005.txt: be present in ACR messages with an Accounting-Record-Type of
../data/rfc/rfc4005.txt- INTERIM_RECORD or STOP_RECORD.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-8.6. Acct-Authentic AVP
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- The Acct-Authentic AVP (AVP Code 45) is of type Enumerated and
--
../data/rfc/rfc4005.txt- 1 RADIUS
../data/rfc/rfc4005.txt- 2 Local
../data/rfc/rfc4005.txt- 3 Remote
../data/rfc/rfc4005.txt- 4 Diameter
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt:8.7. Accounting-Auth-Method AVP
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt: The Accounting-Auth-Method AVP (AVP Code 406) is of type Enumerated.
../data/rfc/rfc4005.txt: A NAS MAY include this AVP in an Accounting-Request message to
../data/rfc/rfc4005.txt- indicate the method used to authenticate the user. (Note that this
../data/rfc/rfc4005.txt- is equivalent to the RADIUS MS-Acct-Auth-Type VSA attribute).
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- The following values are defined:
../data/rfc/rfc4005.txt-
--
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-8.8. Acct-Delay-Time
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- The Acct-Delay-Time AVP (AVP Code 41) is of type Unsigned32 and
../data/rfc/rfc4005.txt- indicates the number of seconds the Diameter client has been trying
../data/rfc/rfc4005.txt: to send the Accounting-Request (ACR). The accounting server may
../data/rfc/rfc4005.txt- subtract this value from the time when the ACR arrives at the server
../data/rfc/rfc4005.txt- to calculate the approximate time of the event that caused the ACR to
../data/rfc/rfc4005.txt- be generated.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- This AVP is not used for retransmissions at the transport level (TCP
--
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-8.9. Acct-Link-Count
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- The Acct-Link-Count AVP (AVP Code 51) is of type Unsigned32 and
../data/rfc/rfc4005.txt- indicates the total number of links that have been active (current or
../data/rfc/rfc4005.txt: closed) in a given multilink session at the time the accounting
../data/rfc/rfc4005.txt: record is generated. This AVP MAY be included in Accounting-Requests
../data/rfc/rfc4005.txt- for any session that may be part of a multilink service.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- The Acct-Link-Count AVP may be used to make it easier for an
../data/rfc/rfc4005.txt: accounting server to know when it has all the records for a given
../data/rfc/rfc4005.txt: multilink service. When the number of Accounting-Requests received
../data/rfc/rfc4005.txt: with Accounting-Record-Type = STOP_RECORD and with the same Acct-
../data/rfc/rfc4005.txt- Multi-Session-Id and unique Session-Ids equals the largest value of
../data/rfc/rfc4005.txt: Acct-Link-Count seen in those Accounting-Requests, all STOP_RECORD
../data/rfc/rfc4005.txt: Accounting-Requests for that multilink service have been received.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt: The following example, showing eight Accounting-Requests, illustrates
../data/rfc/rfc4005.txt- how the Acct-Link-Count AVP is used. In the table below, only the
../data/rfc/rfc4005.txt- relevant AVPs are shown, although additional AVPs containing
../data/rfc/rfc4005.txt: accounting information will be present in the Accounting-Requests.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt: Acct-Multi- Accounting- Acct-
../data/rfc/rfc4005.txt- Session-Id Session-Id Record-Type Link-Count
../data/rfc/rfc4005.txt- --------------------------------------------------------
../data/rfc/rfc4005.txt- "...10" "...10" START_RECORD 1
../data/rfc/rfc4005.txt- "...10" "...11" START_RECORD 2
../data/rfc/rfc4005.txt- "...10" "...11" STOP_RECORD 2
--
../data/rfc/rfc4005.txt- Translation Agent receives a RADIUS message to be translated to a
../data/rfc/rfc4005.txt- Diameter message.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- Note that RADIUS servers are assumed to be stateless. It is also
../data/rfc/rfc4005.txt- quite possible for the RADIUS messages that comprise the session
../data/rfc/rfc4005.txt: (i.e., authentication and accounting messages) to be handled by
../data/rfc/rfc4005.txt- different Translation Agents in the proxy network. Therefore, a
../data/rfc/rfc4005.txt- RADIUS/Diameter Translation Agent SHOULD NOT be assumed to have an
../data/rfc/rfc4005.txt- accurate track on session-state information.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-
--
../data/rfc/rfc4005.txt- Diameter Tunneling Grouped AVP set. If the tunnel information
../data/rfc/rfc4005.txt- contains a Tunnel-Password attribute, the RADIUS encryption
../data/rfc/rfc4005.txt- must be resolved, and the password forwarded, by using Diameter
../data/rfc/rfc4005.txt- security methods.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt: - If the RADIUS message received is an Accounting-Request, the
../data/rfc/rfc4005.txt- Acct-Status-Type attribute value must be converted to a
../data/rfc/rfc4005.txt: Accounting-Record-Type AVP value. If the Acct-Status-Type
../data/rfc/rfc4005.txt- attribute value is STOP, the local server MUST issue a
../data/rfc/rfc4005.txt- Session-Termination-Request message once the Diameter
../data/rfc/rfc4005.txt: Accounting-Answer message has been received.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt: - If the Accounting message contains an Acct-Termination-Cause
../data/rfc/rfc4005.txt- attribute, it should be translated to the equivalent
../data/rfc/rfc4005.txt- Termination-Cause AVP value. (see below)
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt: - If the RADIUS message contains the Accounting-Input-Octets,
../data/rfc/rfc4005.txt: Accounting-Input-Packets, Accounting-Output-Octets, or
../data/rfc/rfc4005.txt: Accounting-Output-Packets, these attributes must be converted
../data/rfc/rfc4005.txt- to the Diameter equivalents. Further, if the Acct-Input-
../data/rfc/rfc4005.txt- Gigawords or Acct-Output-Gigawords attributes are present,
../data/rfc/rfc4005.txt: these must be used to properly compute the Diameter accounting
../data/rfc/rfc4005.txt- AVPs.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- The corresponding Diameter response is always guaranteed to be
../data/rfc/rfc4005.txt- received by the same Translation Agent that translated the original
../data/rfc/rfc4005.txt- request, due to the contents of the Proxy-Info AVP group in the
--
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- - If the Command-Code is set to AA-Answer, the Diameter Session-
../data/rfc/rfc4005.txt- Id AVP is saved in a new RADIUS Class attribute whose format
../data/rfc/rfc4005.txt- consists of the string "Diameter/" followed by the Diameter
../data/rfc/rfc4005.txt- Session Identifier. This will ensure that the subsequent
../data/rfc/rfc4005.txt: Accounting messages, which could be received by any Translation
../data/rfc/rfc4005.txt- Agent, would have access to the original Diameter Session
../data/rfc/rfc4005.txt- Identifier.
../data/rfc/rfc4005.txt- - If a Proxy-State attribute was present in the RADIUS request,
../data/rfc/rfc4005.txt- the same attribute is added in the response. This information
../data/rfc/rfc4005.txt- may be found in the Proxy-Info AVP group, or in a local state
--
../data/rfc/rfc4005.txt- true for any other RADIUS-encrypted attribute values.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- - AVPs of the type Address must be translated to the
../data/rfc/rfc4005.txt- corresponding RADIUS attribute.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt: - If the Accounting-Input-Octets, Accounting-Input-Packets,
../data/rfc/rfc4005.txt: Accounting-Output-Octets, or Accounting-Output-Packets AVPs are
../data/rfc/rfc4005.txt- present, they must be translated to the corresponding RADIUS
../data/rfc/rfc4005.txt- attributes. If the value of the Diameter AVPs do not fit
../data/rfc/rfc4005.txt- within a 32-bit RADIUS attribute, the RADIUS Acct-Input-
../data/rfc/rfc4005.txt- Gigawords and Acct-Output-Gigawords must be used.
../data/rfc/rfc4005.txt-
--
../data/rfc/rfc4005.txt- Attribute Description Defined Nearest Diameter AVP
../data/rfc/rfc4005.txt- -----------------------------------------------------------------
../data/rfc/rfc4005.txt- 3 CHAP-Password RFC 2865 CHAP-Auth Group
../data/rfc/rfc4005.txt- 26 Vendor-Specific RFC 2865 Vendor Specific AVP
../data/rfc/rfc4005.txt- 29 Termination-Action RFC 2865 Authorization-Lifetime
../data/rfc/rfc4005.txt: 40 Acct-Status-Type RFC 2866 Accounting-Record-Type
../data/rfc/rfc4005.txt: 42 Acct-Input-Octets RFC 2866 Accounting-Input-Octets
../data/rfc/rfc4005.txt: 43 Acct-Output-Octets RFC 2866 Accounting-Output-Octets
../data/rfc/rfc4005.txt: 47 Acct-Input-Packets RFC 2866 Accounting-Input-Packets
../data/rfc/rfc4005.txt: 48 Acct-Output-Packets RFC 2866 Accounting-Output-Packets
../data/rfc/rfc4005.txt- 49 Acct-Terminate-Cause RFC 2866 Termination-Cause
../data/rfc/rfc4005.txt: 52 Acct-Input-Gigawords RFC 2869 Accounting-Input-Octets
../data/rfc/rfc4005.txt: 53 Acct-Output-Gigawords RFC 2869 Accounting-Output-Octets
../data/rfc/rfc4005.txt- 80 Message-Authenticator RFC 2869 none - check and discard
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-9.5. Translatable Diameter AVPs
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- In general, Diameter AVPs that are not RADIUS compatible have code
--
../data/rfc/rfc4005.txt- Tunneling | 0+ | 0+ |
../data/rfc/rfc4005.txt- User-Name | 0-1 | 0-1 |
../data/rfc/rfc4005.txt- User-Password | 0-1 | 0 |
../data/rfc/rfc4005.txt- ------------------------------|-----+-----+
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt:10.2. Accounting AVP Tables
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- The tables in this section are used to show which AVPs defined in
../data/rfc/rfc4005.txt- this document are to be present and used in NAS application
../data/rfc/rfc4005.txt: Accounting messages. These AVPs are defined in this document, as
../data/rfc/rfc4005.txt- well as in [BASE] and [RADIUSAcct].
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-
--
../data/rfc/rfc4005.txt-Calhoun, et al. Standards Track [Page 73]
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-RFC 4005 Diameter Network Access Server Application August 2005
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt:10.2.1. Accounting Framed Access AVP Table
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- The table in this section is used when the Service-Type specifies
../data/rfc/rfc4005.txt- Framed Access.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- +-----------+
../data/rfc/rfc4005.txt- | Command |
../data/rfc/rfc4005.txt- |-----+-----+
../data/rfc/rfc4005.txt- Attribute Name | ACR | ACA |
../data/rfc/rfc4005.txt- ---------------------------------------|-----+-----+
../data/rfc/rfc4005.txt: Accounting-Auth-Method | 0-1 | 0 |
../data/rfc/rfc4005.txt: Accounting-Input-Octets | 1 | 0 |
../data/rfc/rfc4005.txt: Accounting-Input-Packets | 1 | 0 |
../data/rfc/rfc4005.txt: Accounting-Output-Octets | 1 | 0 |
../data/rfc/rfc4005.txt: Accounting-Output-Packets | 1 | 0 |
../data/rfc/rfc4005.txt: Accounting-Record-Number | 0-1 | 0-1 |
../data/rfc/rfc4005.txt: Accounting-Record-Type | 1 | 1 |
../data/rfc/rfc4005.txt: Accounting-Realtime-Required | 0-1 | 0-1 |
../data/rfc/rfc4005.txt: Accounting-Sub-Session-Id | 0-1 | 0-1 |
../data/rfc/rfc4005.txt- Acct-Application-Id | 0-1 | 0-1 |
../data/rfc/rfc4005.txt- Acct-Session-Id | 1 | 0-1 |
../data/rfc/rfc4005.txt- Acct-Multi-Session-Id | 0-1 | 0-1 |
../data/rfc/rfc4005.txt- Acct-Authentic | 1 | 0 |
../data/rfc/rfc4005.txt- Acct-Delay-Time | 0-1 | 0 |
--
../data/rfc/rfc4005.txt-Calhoun, et al. Standards Track [Page 75]
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-RFC 4005 Diameter Network Access Server Application August 2005
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt:10.2.2. Accounting Non-Framed Access AVP Table
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- The table in this section is used when the Service-Type specifies
../data/rfc/rfc4005.txt- Non-Framed Access.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- +-----------+
../data/rfc/rfc4005.txt- | Command |
../data/rfc/rfc4005.txt- |-----+-----+
../data/rfc/rfc4005.txt- Attribute Name | ACR | ACA |
../data/rfc/rfc4005.txt- ---------------------------------------|-----+-----+
../data/rfc/rfc4005.txt: Accounting-Auth-Method | 0-1 | 0 |
../data/rfc/rfc4005.txt: Accounting-Input-Octets | 1 | 0 |
../data/rfc/rfc4005.txt: Accounting-Output-Octets | 1 | 0 |
../data/rfc/rfc4005.txt: Accounting-Record-Type | 1 | 1 |
../data/rfc/rfc4005.txt: Accounting-Record-Number | 0-1 | 0-1 |
../data/rfc/rfc4005.txt: Accounting-Realtime-Required | 0-1 | 0-1 |
../data/rfc/rfc4005.txt: Accounting-Sub-Session-Id | 0-1 | 0-1 |
../data/rfc/rfc4005.txt- Acct-Application-Id | 0-1 | 0-1 |
../data/rfc/rfc4005.txt- Acct-Session-Id | 1 | 0-1 |
../data/rfc/rfc4005.txt- Acct-Multi-Session-Id | 0-1 | 0-1 |
../data/rfc/rfc4005.txt- Acct-Authentic | 1 | 0 |
../data/rfc/rfc4005.txt- Acct-Delay-Time | 0-1 | 0 |
--
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- As defined in section 5.5, the CHAP-Algorithm AVP (AVP Code 403) uses
../data/rfc/rfc4005.txt- the values of the "PPP AUTHENTICATION ALGORITHMS" namespace defined
../data/rfc/rfc4005.txt- in [PPPCHAP].
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt:11.5. Accounting-Auth-Method AVP Values
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt: As defined in section 8.6, the Accounting-Auth-Method AVP (AVP Code
../data/rfc/rfc4005.txt- 406) defines the values 1 - 5. All remaining values are available
../data/rfc/rfc4005.txt- for assignment via IETF Consensus [IANA].
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-11.6. Origin-AAA-Protocol AVP Values
../data/rfc/rfc4005.txt-
--
../data/rfc/rfc4005.txt- [BASE] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and
../data/rfc/rfc4005.txt- J. Arkko, "Diameter Base Protocol", RFC 3588,
../data/rfc/rfc4005.txt- September 2003.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- [DiamTrans] Aboba, B. and J. Wood, "Authentication, Authorization
../data/rfc/rfc4005.txt: and Accounting (AAA) Transport Profile", RFC 3539,
../data/rfc/rfc4005.txt- June 2003.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- [RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
../data/rfc/rfc4005.txt- "Remote Authentication Dial In User Service (RADIUS)",
../data/rfc/rfc4005.txt- RFC 2865, June 2000.
--
../data/rfc/rfc4005.txt- <http://www.nanpa.com/number_resource_info/
../data/rfc/rfc4005.txt- ani_ii_assignments.html>
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt-13.2. Informative References
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt: [RADIUSAcct] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- [RADIUSExt] Rigney, C., Willats, W., and P. Calhoun, "RADIUS
../data/rfc/rfc4005.txt- Extensions", RFC 2869, June 2000.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- [RADTunnels] Zorn, G., Leifer, D., Rubens, A., Shriver, J.,
../data/rfc/rfc4005.txt- Holdrege, M., and I. Goyret, "RADIUS Attributes for
../data/rfc/rfc4005.txt- Tunnel Protocol Support", RFC 2868, June 2000.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt: [RADTunlAcct] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting
../data/rfc/rfc4005.txt- Modifications for Tunnel Protocol Support", RFC 2867,
../data/rfc/rfc4005.txt- June 2000.
../data/rfc/rfc4005.txt-
../data/rfc/rfc4005.txt- [RADDynAuth] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
../data/rfc/rfc4005.txt- Aboba, "Dynamic Authorization Extensions to Remote
--
../data/rfc/rfc2837.txt- The Status Group ............................................16
../data/rfc/rfc2837.txt- The FxPort Status Table ...................................16
../data/rfc/rfc2837.txt- The FxPort Physical Level Table ...........................18
../data/rfc/rfc2837.txt- The FxPort Fabric Login Table .............................20
../data/rfc/rfc2837.txt- The Error Group .............................................24
../data/rfc/rfc2837.txt: The Accounting Groups........................................27
../data/rfc/rfc2837.txt: The Class 1 Accounting Table ..............................27
../data/rfc/rfc2837.txt: The Class 2 Accounting Table ..............................31
../data/rfc/rfc2837.txt: The Class 3 Accounting Table ..............................33
../data/rfc/rfc2837.txt- The Capability Group ........................................35
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt-Teow Standards Track [Page 1]
--
../data/rfc/rfc2837.txt- with its managed objects. The managed objects are divided as follow:
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt- - the Configuration group
../data/rfc/rfc2837.txt- - the Status group
../data/rfc/rfc2837.txt- - the Error group
../data/rfc/rfc2837.txt: - the Accounting group
../data/rfc/rfc2837.txt- - the Capability group
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt- In each group, scalar objects and table entries are defined.
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt- The Configuration group contains configuration and service parameters
--
../data/rfc/rfc2837.txt-Teow Standards Track [Page 5]
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt-RFC 2837 FC Fabric Element MIB May 2000
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt: The Accounting group contains statistic data suitable for deriving
../data/rfc/rfc2837.txt: accounting and performance information.
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt- The Capability group contains parameters indicating the inherent
../data/rfc/rfc2837.txt- capability of the Fabric Element and each FxPort.
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt-3. Object Definitions
--
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt- fcFeConfig OBJECT IDENTIFIER ::= { fcFeMIBObjects 1 }
../data/rfc/rfc2837.txt- fcFeStatus OBJECT IDENTIFIER ::= { fcFeMIBObjects 2 }
../data/rfc/rfc2837.txt- fcFeError OBJECT IDENTIFIER ::= { fcFeMIBObjects 3 }
../data/rfc/rfc2837.txt: fcFeAccounting OBJECT IDENTIFIER ::= { fcFeMIBObjects 4 }
../data/rfc/rfc2837.txt- fcFeCapabilities OBJECT IDENTIFIER ::= { fcFeMIBObjects 5 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt- -- Textual Conventions
../data/rfc/rfc2837.txt- MilliSeconds ::= TEXTUAL-CONVENTION
../data/rfc/rfc2837.txt- STATUS current
--
../data/rfc/rfc2837.txt- "The number of Offline Sequence issued by this FxPort."
../data/rfc/rfc2837.txt- ::= { fcFxPortErrorEntry 12 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt: -- Accounting Groups:
../data/rfc/rfc2837.txt: -- (1) Class 1 Accounting Group,
../data/rfc/rfc2837.txt: -- (2) Class 2 Accounting Group, and
../data/rfc/rfc2837.txt: -- (3) Class 3 Accounting Group.
../data/rfc/rfc2837.txt: -- Each group consists of a table that contains accounting
../data/rfc/rfc2837.txt- -- information for the FxPorts in the Fabric Element.
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt: -- the Class 1 Accounting table
../data/rfc/rfc2837.txt- -- This table contains, one entry for each FxPort in the Fabric
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt-Teow Standards Track [Page 27]
--
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt- -- Element, Counter32s for certain types of events occurred in the
../data/rfc/rfc2837.txt- -- the FxPorts since the the management agent has re-initialized.
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt: fcFxPortC1AccountingTable OBJECT-TYPE
../data/rfc/rfc2837.txt: SYNTAX SEQUENCE OF FcFxPortC1AccountingEntry
../data/rfc/rfc2837.txt- MAX-ACCESS not-accessible
../data/rfc/rfc2837.txt- STATUS current
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt- "A table that contains, one entry for each FxPort in the
../data/rfc/rfc2837.txt: Fabric Element, Class 1 accounting information recorded
../data/rfc/rfc2837.txt- since the management agent has re-initialized."
../data/rfc/rfc2837.txt: ::= { fcFeAccounting 1 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt: fcFxPortC1AccountingEntry OBJECT-TYPE
../data/rfc/rfc2837.txt: SYNTAX FcFxPortC1AccountingEntry
../data/rfc/rfc2837.txt- MAX-ACCESS not-accessible
../data/rfc/rfc2837.txt- STATUS current
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt: "An entry containing Class 1 accounting information for each
../data/rfc/rfc2837.txt- FxPort."
../data/rfc/rfc2837.txt- AUGMENTS { fcFxPortEntry }
../data/rfc/rfc2837.txt: ::= { fcFxPortC1AccountingTable 1 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt: FcFxPortC1AccountingEntry ::=
../data/rfc/rfc2837.txt- SEQUENCE {
../data/rfc/rfc2837.txt- fcFxPortC1InFrames
../data/rfc/rfc2837.txt- Counter32,
../data/rfc/rfc2837.txt- fcFxPortC1OutFrames
../data/rfc/rfc2837.txt- Counter32,
--
../data/rfc/rfc2837.txt- MAX-ACCESS read-only
../data/rfc/rfc2837.txt- STATUS current
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt- "The number of Class 1 frames (other than Class 1 connect-
../data/rfc/rfc2837.txt- request) received by this FxPort from its attached NxPort."
../data/rfc/rfc2837.txt: ::= { fcFxPortC1AccountingEntry 1 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt- fcFxPortC1OutFrames OBJECT-TYPE
../data/rfc/rfc2837.txt- SYNTAX Counter32
../data/rfc/rfc2837.txt- MAX-ACCESS read-only
../data/rfc/rfc2837.txt- STATUS current
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt- "The number of Class 1 frames (other than Class 1 connect-
../data/rfc/rfc2837.txt- request) delivered through this FxPort to its attached
../data/rfc/rfc2837.txt- NxPort."
../data/rfc/rfc2837.txt: ::= { fcFxPortC1AccountingEntry 2 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt- fcFxPortC1InOctets OBJECT-TYPE
../data/rfc/rfc2837.txt- SYNTAX Counter32
../data/rfc/rfc2837.txt- MAX-ACCESS read-only
../data/rfc/rfc2837.txt- STATUS current
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt- "The number of Class 1 frame octets, including the frame
../data/rfc/rfc2837.txt- delimiters, received by this FxPort from its attached
../data/rfc/rfc2837.txt- NxPort."
../data/rfc/rfc2837.txt: ::= { fcFxPortC1AccountingEntry 3 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt- fcFxPortC1OutOctets OBJECT-TYPE
../data/rfc/rfc2837.txt- SYNTAX Counter32
../data/rfc/rfc2837.txt- MAX-ACCESS read-only
../data/rfc/rfc2837.txt- STATUS current
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt- "The number of Class 1 frame octets, including the frame
../data/rfc/rfc2837.txt- delimiters, delivered through this FxPort its attached
../data/rfc/rfc2837.txt- NxPort."
../data/rfc/rfc2837.txt: ::= { fcFxPortC1AccountingEntry 4 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt- fcFxPortC1Discards OBJECT-TYPE
../data/rfc/rfc2837.txt- SYNTAX Counter32
../data/rfc/rfc2837.txt- MAX-ACCESS read-only
../data/rfc/rfc2837.txt- STATUS current
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt- "The number of Class 1 frames discarded by this FxPort."
../data/rfc/rfc2837.txt: ::= { fcFxPortC1AccountingEntry 5 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt- fcFxPortC1FbsyFrames OBJECT-TYPE
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt-
--
../data/rfc/rfc2837.txt- MAX-ACCESS read-only
../data/rfc/rfc2837.txt- STATUS current
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt- "The number of F_BSY frames generated by this FxPort against
../data/rfc/rfc2837.txt- Class 1 connect-request."
../data/rfc/rfc2837.txt: ::= { fcFxPortC1AccountingEntry 6 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt- fcFxPortC1FrjtFrames OBJECT-TYPE
../data/rfc/rfc2837.txt- SYNTAX Counter32
../data/rfc/rfc2837.txt- MAX-ACCESS read-only
../data/rfc/rfc2837.txt- STATUS current
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt- "The number of F_RJT frames generated by this FxPort against
../data/rfc/rfc2837.txt- Class 1 connect-request."
../data/rfc/rfc2837.txt: ::= { fcFxPortC1AccountingEntry 7 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt- fcFxPortC1InConnections OBJECT-TYPE
../data/rfc/rfc2837.txt- SYNTAX Counter32
../data/rfc/rfc2837.txt- MAX-ACCESS read-only
../data/rfc/rfc2837.txt- STATUS current
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt- "The number of Class 1 connections successfully established
../data/rfc/rfc2837.txt- in which the attached NxPort is the source of the connect-
../data/rfc/rfc2837.txt- request."
../data/rfc/rfc2837.txt: ::= { fcFxPortC1AccountingEntry 8 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt- fcFxPortC1OutConnections OBJECT-TYPE
../data/rfc/rfc2837.txt- SYNTAX Counter32
../data/rfc/rfc2837.txt- MAX-ACCESS read-only
../data/rfc/rfc2837.txt- STATUS current
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt- "The number of Class 1 connections successfully established
../data/rfc/rfc2837.txt- in which the attached NxPort is the destination of the
../data/rfc/rfc2837.txt- connect-request."
../data/rfc/rfc2837.txt: ::= { fcFxPortC1AccountingEntry 9 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt- fcFxPortC1ConnTime OBJECT-TYPE
../data/rfc/rfc2837.txt- SYNTAX MilliSeconds
../data/rfc/rfc2837.txt- UNITS "milliseconds"
../data/rfc/rfc2837.txt- MAX-ACCESS read-only
--
../data/rfc/rfc2837.txt-Teow Standards Track [Page 30]
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt-RFC 2837 FC Fabric Element MIB May 2000
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt: ::= { fcFxPortC1AccountingEntry 10 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt: -- the Class 2 Accounting table
../data/rfc/rfc2837.txt- -- This table contains, one entry for each FxPort in the Fabric
../data/rfc/rfc2837.txt- -- Element, Counter32s for certain types of events occurred in the
../data/rfc/rfc2837.txt- -- the FxPorts since the the management agent has re-initialized.
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt: fcFxPortC2AccountingTable OBJECT-TYPE
../data/rfc/rfc2837.txt: SYNTAX SEQUENCE OF FcFxPortC2AccountingEntry
../data/rfc/rfc2837.txt- MAX-ACCESS not-accessible
../data/rfc/rfc2837.txt- STATUS current
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt- "A table that contains, one entry for each FxPort in the
../data/rfc/rfc2837.txt: Fabric Element, Class 2 accounting information recorded
../data/rfc/rfc2837.txt- since the management agent has re-initialized."
../data/rfc/rfc2837.txt: ::= { fcFeAccounting 2 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt: fcFxPortC2AccountingEntry OBJECT-TYPE
../data/rfc/rfc2837.txt: SYNTAX FcFxPortC2AccountingEntry
../data/rfc/rfc2837.txt- MAX-ACCESS not-accessible
../data/rfc/rfc2837.txt- STATUS current
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt: "An entry containing Class 2 accounting information for each
../data/rfc/rfc2837.txt- FxPort."
../data/rfc/rfc2837.txt- AUGMENTS { fcFxPortEntry }
../data/rfc/rfc2837.txt: ::= { fcFxPortC2AccountingTable 1 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt: FcFxPortC2AccountingEntry ::=
../data/rfc/rfc2837.txt- SEQUENCE {
../data/rfc/rfc2837.txt- fcFxPortC2InFrames
../data/rfc/rfc2837.txt- Counter32,
../data/rfc/rfc2837.txt- fcFxPortC2OutFrames
../data/rfc/rfc2837.txt- Counter32,
--
../data/rfc/rfc2837.txt- MAX-ACCESS read-only
../data/rfc/rfc2837.txt- STATUS current
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt- "The number of Class 2 frames received by this FxPort from
../data/rfc/rfc2837.txt- its attached NxPort."
../data/rfc/rfc2837.txt: ::= { fcFxPortC2AccountingEntry 1 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt- fcFxPortC2OutFrames OBJECT-TYPE
../data/rfc/rfc2837.txt- SYNTAX Counter32
../data/rfc/rfc2837.txt- MAX-ACCESS read-only
../data/rfc/rfc2837.txt- STATUS current
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt- "The number of Class 2 frames delivered through this FxPort
../data/rfc/rfc2837.txt- to its attached NxPort."
../data/rfc/rfc2837.txt: ::= { fcFxPortC2AccountingEntry 2 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt- fcFxPortC2InOctets OBJECT-TYPE
../data/rfc/rfc2837.txt- SYNTAX Counter32
../data/rfc/rfc2837.txt- MAX-ACCESS read-only
../data/rfc/rfc2837.txt- STATUS current
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt- "The number of Class 2 frame octets, including the frame
../data/rfc/rfc2837.txt- delimiters, received by this FxPort from its attached
../data/rfc/rfc2837.txt- NxPort."
../data/rfc/rfc2837.txt: ::= { fcFxPortC2AccountingEntry 3 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt- fcFxPortC2OutOctets OBJECT-TYPE
../data/rfc/rfc2837.txt- SYNTAX Counter32
../data/rfc/rfc2837.txt- MAX-ACCESS read-only
../data/rfc/rfc2837.txt- STATUS current
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt- "The number of Class 2 frame octets, including the frame
../data/rfc/rfc2837.txt- delimiters, delivered through this FxPort to its attached
../data/rfc/rfc2837.txt- NxPort."
../data/rfc/rfc2837.txt: ::= { fcFxPortC2AccountingEntry 4 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt- fcFxPortC2Discards OBJECT-TYPE
../data/rfc/rfc2837.txt- SYNTAX Counter32
../data/rfc/rfc2837.txt- MAX-ACCESS read-only
../data/rfc/rfc2837.txt- STATUS current
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt- "The number of Class 2 frames discarded by this FxPort."
../data/rfc/rfc2837.txt: ::= { fcFxPortC2AccountingEntry 5 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt- fcFxPortC2FbsyFrames OBJECT-TYPE
../data/rfc/rfc2837.txt- SYNTAX Counter32
../data/rfc/rfc2837.txt- MAX-ACCESS read-only
../data/rfc/rfc2837.txt-
--
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt- STATUS current
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt- "The number of F_BSY frames generated by this FxPort against
../data/rfc/rfc2837.txt- Class 2 frames."
../data/rfc/rfc2837.txt: ::= { fcFxPortC2AccountingEntry 6 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt- fcFxPortC2FrjtFrames OBJECT-TYPE
../data/rfc/rfc2837.txt- SYNTAX Counter32
../data/rfc/rfc2837.txt- MAX-ACCESS read-only
../data/rfc/rfc2837.txt- STATUS current
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt- "The number of F_RJT frames generated by this FxPort against
../data/rfc/rfc2837.txt- Class 2 frames."
../data/rfc/rfc2837.txt: ::= { fcFxPortC2AccountingEntry 7 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt: -- the Class 3 Accounting Group
../data/rfc/rfc2837.txt- -- This table contains, one entry for each FxPort in the Fabric
../data/rfc/rfc2837.txt- -- Element, Counter32s for certain types of events occurred in the
../data/rfc/rfc2837.txt- -- the FxPorts since the management agent has re-initialized.
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt: fcFxPortC3AccountingTable OBJECT-TYPE
../data/rfc/rfc2837.txt: SYNTAX SEQUENCE OF FcFxPortC3AccountingEntry
../data/rfc/rfc2837.txt- MAX-ACCESS not-accessible
../data/rfc/rfc2837.txt- STATUS current
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt- "A table that contains, one entry for each FxPort in the
../data/rfc/rfc2837.txt: Fabric Element, Class 3 accounting information recorded
../data/rfc/rfc2837.txt- since the management agent has re-initialized."
../data/rfc/rfc2837.txt: ::= { fcFeAccounting 3 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt: fcFxPortC3AccountingEntry OBJECT-TYPE
../data/rfc/rfc2837.txt: SYNTAX FcFxPortC3AccountingEntry
../data/rfc/rfc2837.txt- MAX-ACCESS not-accessible
../data/rfc/rfc2837.txt- STATUS current
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt: "An entry containing Class 3 accounting information for each
../data/rfc/rfc2837.txt- FxPort."
../data/rfc/rfc2837.txt- AUGMENTS { fcFxPortEntry }
../data/rfc/rfc2837.txt: ::= { fcFxPortC3AccountingTable 1 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt: FcFxPortC3AccountingEntry ::=
../data/rfc/rfc2837.txt- SEQUENCE {
../data/rfc/rfc2837.txt- fcFxPortC3InFrames
../data/rfc/rfc2837.txt- Counter32,
../data/rfc/rfc2837.txt- fcFxPortC3OutFrames
../data/rfc/rfc2837.txt- Counter32,
--
../data/rfc/rfc2837.txt- MAX-ACCESS read-only
../data/rfc/rfc2837.txt- STATUS current
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt- "The number of Class 3 frames received by this FxPort from
../data/rfc/rfc2837.txt- its attached NxPort."
../data/rfc/rfc2837.txt: ::= { fcFxPortC3AccountingEntry 1 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt- fcFxPortC3OutFrames OBJECT-TYPE
../data/rfc/rfc2837.txt- SYNTAX Counter32
../data/rfc/rfc2837.txt- MAX-ACCESS read-only
../data/rfc/rfc2837.txt- STATUS current
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt- "The number of Class 3 frames delivered through this FxPort
../data/rfc/rfc2837.txt- to its attached NxPort."
../data/rfc/rfc2837.txt: ::= { fcFxPortC3AccountingEntry 2 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt- fcFxPortC3InOctets OBJECT-TYPE
../data/rfc/rfc2837.txt- SYNTAX Counter32
../data/rfc/rfc2837.txt- MAX-ACCESS read-only
../data/rfc/rfc2837.txt- STATUS current
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt- "The number of Class 3 frame octets, including the frame
../data/rfc/rfc2837.txt- delimiters, received by this FxPort from its attached
../data/rfc/rfc2837.txt- NxPort."
../data/rfc/rfc2837.txt: ::= { fcFxPortC3AccountingEntry 3 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt- fcFxPortC3OutOctets OBJECT-TYPE
../data/rfc/rfc2837.txt- SYNTAX Counter32
../data/rfc/rfc2837.txt- MAX-ACCESS read-only
../data/rfc/rfc2837.txt- STATUS current
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt- "The number of Class 3 frame octets, including the frame
../data/rfc/rfc2837.txt- delimiters, delivered through this FxPort to its attached
../data/rfc/rfc2837.txt- NxPort."
../data/rfc/rfc2837.txt: ::= { fcFxPortC3AccountingEntry 4 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt- fcFxPortC3Discards OBJECT-TYPE
../data/rfc/rfc2837.txt- SYNTAX Counter32
../data/rfc/rfc2837.txt- MAX-ACCESS read-only
../data/rfc/rfc2837.txt-
--
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt- STATUS current
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt- "The number of Class 3 frames discarded by this FxPort."
../data/rfc/rfc2837.txt: ::= { fcFxPortC3AccountingEntry 5 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt- -- The Capability Group - consists of a table describing
../data/rfc/rfc2837.txt- -- information about what each FxPort is inherently capable
../data/rfc/rfc2837.txt- -- of operating or supporting.
--
../data/rfc/rfc2837.txt- which implement the FIBRE-CHANNEL-FE-MIB."
../data/rfc/rfc2837.txt- MODULE -- this module
../data/rfc/rfc2837.txt- MANDATORY-GROUPS { fcFeConfigGroup, fcFeStatusGroup,
../data/rfc/rfc2837.txt- fcFeErrorGroup, fcFeCapabilitiesGroup }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt: GROUP fcFeClass1AccountingGroup
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt- "This group is mandatory for all fibre channel fabric
../data/rfc/rfc2837.txt- elements which support class 1 frames."
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt: GROUP fcFeClass2AccountingGroup
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt- "This group is mandatory for all fibre channel fabric
../data/rfc/rfc2837.txt- elements which support class 2 frames."
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt: GROUP fcFeClass3AccountingGroup
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt- "This group is mandatory for all fibre channel fabric
../data/rfc/rfc2837.txt- elements which support class 3 frames."
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt- OBJECT fcFeFabricName
--
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt- "A collection of objects providing various error
../data/rfc/rfc2837.txt- statistics detected by the FxPorts."
../data/rfc/rfc2837.txt- ::= { fcFeMIBGroups 3 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt: fcFeClass1AccountingGroup OBJECT-GROUP
../data/rfc/rfc2837.txt- OBJECTS { fcFxPortC1InFrames, fcFxPortC1OutFrames,
../data/rfc/rfc2837.txt- fcFxPortC1InOctets, fcFxPortC1OutOctets,
../data/rfc/rfc2837.txt- fcFxPortC1Discards, fcFxPortC1FbsyFrames,
../data/rfc/rfc2837.txt- fcFxPortC1FrjtFrames, fcFxPortC1InConnections,
../data/rfc/rfc2837.txt- fcFxPortC1OutConnections, fcFxPortC1ConnTime
--
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt- "A collection of objects providing various class 1
../data/rfc/rfc2837.txt- performance statistics detected by the FxPorts."
../data/rfc/rfc2837.txt- ::= { fcFeMIBGroups 4 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt: fcFeClass2AccountingGroup OBJECT-GROUP
../data/rfc/rfc2837.txt- OBJECTS { fcFxPortC2InFrames, fcFxPortC2OutFrames,
../data/rfc/rfc2837.txt- fcFxPortC2InOctets, fcFxPortC2OutOctets,
../data/rfc/rfc2837.txt- fcFxPortC2Discards, fcFxPortC2FbsyFrames,
../data/rfc/rfc2837.txt- fcFxPortC2FrjtFrames
../data/rfc/rfc2837.txt- }
--
../data/rfc/rfc2837.txt- DESCRIPTION
../data/rfc/rfc2837.txt- "A collection of objects providing various class 2
../data/rfc/rfc2837.txt- performance statistics detected by the FxPorts."
../data/rfc/rfc2837.txt- ::= { fcFeMIBGroups 5 }
../data/rfc/rfc2837.txt-
../data/rfc/rfc2837.txt: fcFeClass3AccountingGroup OBJECT-GROUP
../data/rfc/rfc2837.txt- OBJECTS { fcFxPortC3InFrames, fcFxPortC3OutFrames,
../data/rfc/rfc2837.txt- fcFxPortC3InOctets, fcFxPortC3OutOctets,
../data/rfc/rfc2837.txt- fcFxPortC3Discards
../data/rfc/rfc2837.txt- }
../data/rfc/rfc2837.txt-
--
../data/rfc/rfc3869.txt-
../data/rfc/rfc3869.txt- Included in this topic are a wide variety of issues. The more
../data/rfc/rfc3869.txt- distributed and dynamic nature of partially or completely self-
../data/rfc/rfc3869.txt- organizing routing systems (including the associated end nodes)
../data/rfc/rfc3869.txt- creates unique security challenges (especially relating to
../data/rfc/rfc3869.txt: Authorization, Authentication, and Accounting, and relating to key
../data/rfc/rfc3869.txt- management). Scalability of wireless networks can be difficult to
../data/rfc/rfc3869.txt- measure or to achieve. Enforced hierarchy is one approach, but can
../data/rfc/rfc3869.txt- be very limiting. Alternative, less constraining approaches to
../data/rfc/rfc3869.txt- wireless scalability are desired. Because wireless link-layer
../data/rfc/rfc3869.txt- protocols usually have some knowledge of current link characteristics
--
../data/rfc/rfc437.txt- 'ARPA'.
../data/rfc/rfc437.txt-
../data/rfc/rfc437.txt- 'LOGOUT' <CA>
../data/rfc/rfc437.txt-
../data/rfc/rfc437.txt- Logs the user out and disables job-oriented commands and billing of
../data/rfc/rfc437.txt: subsequent activity to the previously specified accounting
../data/rfc/rfc437.txt- parameters. As with 'DISCONNECT', any jobs the terminal has active
../data/rfc/rfc437.txt- are purged.
../data/rfc/rfc437.txt-
../data/rfc/rfc437.txt- 'MONITOR' (<tty list>|<CA>) <CA>
../data/rfc/rfc437.txt-
--
../data/rfc/rfc3457.txt- Until recently, remote access has typically been characterized by
../data/rfc/rfc3457.txt- dial-up users accessing the target network via the Public Switched
../data/rfc/rfc3457.txt- Telephone Network (PSTN), with the dial-up connection terminating at
../data/rfc/rfc3457.txt- a Network Access Server (NAS) within the target domain. The
../data/rfc/rfc3457.txt- protocols facilitating this have usually been PPP-based, and access
../data/rfc/rfc3457.txt: control, authorization, and accounting functions have typically been
../data/rfc/rfc3457.txt- provided using one or more of a number of available mechanisms,
../data/rfc/rfc3457.txt- including RADIUS [RADIUS].
../data/rfc/rfc3457.txt-
../data/rfc/rfc3457.txt-
../data/rfc/rfc3457.txt-
--
../data/rfc/rfc3457.txt-2.1.5 Compatibility With Legacy Remote Access Mechanisms
../data/rfc/rfc3457.txt-
../data/rfc/rfc3457.txt- There are a number of currently deployed remote access mechanisms
../data/rfc/rfc3457.txt- which were installed prior to the deployment of IPsec. Typically,
../data/rfc/rfc3457.txt- these are dialup systems which rely upon RADIUS for user
../data/rfc/rfc3457.txt: authentication and accounting, but there are other mechanisms as
../data/rfc/rfc3457.txt- well. An ideal IPsec remote access solution might utilize the
../data/rfc/rfc3457.txt- components of the underlying framework without modification.
../data/rfc/rfc3457.txt- Inasmuch as this is possible, this should be a goal. However, there
../data/rfc/rfc3457.txt- may be cases where this simply cannot be accomplished, due to
../data/rfc/rfc3457.txt- security and/or other considerations. In such cases, the IPsec
--
../data/rfc/rfc3457.txt-
../data/rfc/rfc3457.txt- In general, proposed IPsec remote access mechanisms should meet the
../data/rfc/rfc3457.txt- following goals:
../data/rfc/rfc3457.txt-
../data/rfc/rfc3457.txt- o should provide direct support for legacy user authentication
../data/rfc/rfc3457.txt: and accounting systems such as RADIUS
../data/rfc/rfc3457.txt-
../data/rfc/rfc3457.txt-
../data/rfc/rfc3457.txt-
../data/rfc/rfc3457.txt-Kelly & Ramamoorthi Informational [Page 9]
../data/rfc/rfc3457.txt-
--
../data/rfc/rfc3004.txt-1. Introduction
../data/rfc/rfc3004.txt-
../data/rfc/rfc3004.txt- DHCP administrators may define specific user class identifiers to
../data/rfc/rfc3004.txt- convey information about a client's software configuration or about
../data/rfc/rfc3004.txt- its user's preferences. For example, the User Class option can be
../data/rfc/rfc3004.txt: used to configure all clients of people in the accounting department
../data/rfc/rfc3004.txt- with a different printer than clients of people in the marketing
../data/rfc/rfc3004.txt- department.
../data/rfc/rfc3004.txt-
../data/rfc/rfc3004.txt-
../data/rfc/rfc3004.txt-
--
../data/rfc/rfc2795.txt-Table of Contents
../data/rfc/rfc2795.txt-
../data/rfc/rfc2795.txt- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
../data/rfc/rfc2795.txt- 2. Objects In The Suite . . . . . . . . . . . . . . . . . . . 2
../data/rfc/rfc2795.txt- 3. IMPS Packet Structure . . . . . . . . . . . . . . . . . . 4
../data/rfc/rfc2795.txt: 4. Infinite Threshold Accounting Gadget (I-TAG) Encoding . . 5
../data/rfc/rfc2795.txt- 5. KEEPER Specification . . . . . . . . . . . . . . . . . . . 6
../data/rfc/rfc2795.txt- 5.1 KEEPER Message Request Codes (ZOO-to-SIMIAN) . . . . . . 7
../data/rfc/rfc2795.txt- 5.2 KEEPER Message Response Codes (SIMIAN-to-ZOO) . . . . . 8
../data/rfc/rfc2795.txt- 5.3 Requirements for KEEPER Request and Response Codes . . . 8
../data/rfc/rfc2795.txt- 5.4 Example ZOO-to-SIMIAN Exchanges using KEEPER . . . . . . 9
--
../data/rfc/rfc2795.txt-Christey Informational [Page 4]
../data/rfc/rfc2795.txt-
../data/rfc/rfc2795.txt-RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000
../data/rfc/rfc2795.txt-
../data/rfc/rfc2795.txt-
../data/rfc/rfc2795.txt:4. Infinite Threshold Accounting Gadget (I-TAG) Encoding
../data/rfc/rfc2795.txt-
../data/rfc/rfc2795.txt- Each SIMIAN requires a unique identifier within IMPS. This section
../data/rfc/rfc2795.txt- describes design considerations for the IMPS identifier, referred to
../data/rfc/rfc2795.txt: as an Infinite Threshold Accounting Gadget (I-TAG). The I-TAG can
../data/rfc/rfc2795.txt- represent numbers of any size.
../data/rfc/rfc2795.txt-
../data/rfc/rfc2795.txt- To uniquely identify each SIMIAN, a system is required that is
../data/rfc/rfc2795.txt- capable of representing an infinite number of identifiers. The set
../data/rfc/rfc2795.txt- of all integers can be used as a compact representation. However,
--
../data/rfc/rfc2835.txt-Pittet Standards Track [Page 10]
../data/rfc/rfc2835.txt-
../data/rfc/rfc2835.txt-RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
../data/rfc/rfc2835.txt-
../data/rfc/rfc2835.txt-
../data/rfc/rfc2835.txt: For HIPPI-6400 the byte accounting is:
../data/rfc/rfc2835.txt-
../data/rfc/rfc2835.txt- HIPPI-6400-PH Header 16 bytes
../data/rfc/rfc2835.txt- IEEE 802.2 LLC/SNAP Headers 8 bytes
../data/rfc/rfc2835.txt- Maximum IP packet size (MTU) 65280 bytes
../data/rfc/rfc2835.txt- Unused expansion room 232 bytes
../data/rfc/rfc2835.txt- ------------
../data/rfc/rfc2835.txt- Total 65536 bytes (64K)
../data/rfc/rfc2835.txt-
../data/rfc/rfc2835.txt: In contrast, the HIPPI-800 accounting is:
../data/rfc/rfc2835.txt-
../data/rfc/rfc2835.txt- HIPPI-800-FP Header 8 bytes
../data/rfc/rfc2835.txt- HIPPI-800-LE Header 24 bytes
../data/rfc/rfc2835.txt- IEEE 802.2 LLC/SNAP Headers 8 bytes
../data/rfc/rfc2835.txt- Unused expansion room 216 bytes
--
../data/rfc/rfc2835.txt- ports, the upper bound on the bandwidth that such a service can
../data/rfc/rfc2835.txt- broadcast is:
../data/rfc/rfc2835.txt-
../data/rfc/rfc2835.txt- (total bandwidth)/(n+1)
../data/rfc/rfc2835.txt-
../data/rfc/rfc2835.txt: since each message must first enter the broadcast server, accounting
../data/rfc/rfc2835.txt- for the additional 1, and then be sent to all n ports. The broadcast
../data/rfc/rfc2835.txt- server could forward the message destined to the port on which it
../data/rfc/rfc2835.txt- runs internally, thus reducing (n+1) to (n) in a first optimization.
../data/rfc/rfc2835.txt-
../data/rfc/rfc2835.txt- This service is adequate for the standard networking protocols such
--
../data/rfc/rfc6988.txt- o evaluating the effectiveness of energy-saving policies and
../data/rfc/rfc6988.txt- measures
../data/rfc/rfc6988.txt-
../data/rfc/rfc6988.txt- o deriving, implementing, and testing power management strategies
../data/rfc/rfc6988.txt-
../data/rfc/rfc6988.txt: o accounting for the total power received and provided by an entity,
../data/rfc/rfc6988.txt- a network, or a service
../data/rfc/rfc6988.txt-
../data/rfc/rfc6988.txt- o predicting an entity's reliability based on power usage
../data/rfc/rfc6988.txt-
../data/rfc/rfc6988.txt- o choosing the time of the next maintenance cycle for an entity
--
../data/rfc/rfc6988.txt- just the received and provided energy; therefore, monitored data
../data/rfc/rfc6988.txt- requires protection. This protection includes authentication and
../data/rfc/rfc6988.txt- authorization of entities requesting access to monitored data as well
../data/rfc/rfc6988.txt- as confidentiality protection during transmission of monitored data.
../data/rfc/rfc6988.txt- Privacy of stored data in an entity must be taken into account.
../data/rfc/rfc6988.txt: Monitored data may be used as input to control, accounting, and other
../data/rfc/rfc6988.txt- actions, so integrity of transmitted information and authentication
../data/rfc/rfc6988.txt- of the origin may be needed.
../data/rfc/rfc6988.txt-
../data/rfc/rfc6988.txt-9.1. Secure Energy Management
../data/rfc/rfc6988.txt-
--
../data/rfc/rfc5866.txt- 6. QoS Application State Machine . . . . . . . . . . . . . . . . 34
../data/rfc/rfc5866.txt- 6.1. Supplemented States for Push Mode . . . . . . . . . . . . 34
../data/rfc/rfc5866.txt- 7. QoS Application AVPs . . . . . . . . . . . . . . . . . . . . . 35
../data/rfc/rfc5866.txt- 7.1. Reused Base Protocol AVPs . . . . . . . . . . . . . . . . 36
../data/rfc/rfc5866.txt- 7.2. QoS Application-Defined AVPs . . . . . . . . . . . . . . . 36
../data/rfc/rfc5866.txt: 8. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 37
../data/rfc/rfc5866.txt-
../data/rfc/rfc5866.txt-
../data/rfc/rfc5866.txt-
../data/rfc/rfc5866.txt-
../data/rfc/rfc5866.txt-
--
../data/rfc/rfc5866.txt-
../data/rfc/rfc5866.txt-
../data/rfc/rfc5866.txt- The following terms are used in this document:
../data/rfc/rfc5866.txt-
../data/rfc/rfc5866.txt- AAA Cloud
../data/rfc/rfc5866.txt: An infrastructure of Authentication, Authorization, and Accounting
../data/rfc/rfc5866.txt- (AAA) entities (clients, agents, servers) communicating via a AAA
../data/rfc/rfc5866.txt- protocol over trusted, secure connections. It offers
../data/rfc/rfc5866.txt: authentication, authorization, and accounting services to
../data/rfc/rfc5866.txt- applications in local and roaming scenarios. Diameter and RADIUS
../data/rfc/rfc5866.txt- [RFC2865] are both widely deployed AAA protocols.
../data/rfc/rfc5866.txt-
../data/rfc/rfc5866.txt- Application Endpoint (AppE)
../data/rfc/rfc5866.txt- An Application Endpoint is an entity in an end-user device that
--
../data/rfc/rfc5866.txt- regardless of whether or not the AE communicates with an AppS,
../data/rfc/rfc5866.txt- routers are insulated from the details of particular applications and
../data/rfc/rfc5866.txt- need not know that Application Servers are involved. Also, the AAA
../data/rfc/rfc5866.txt- cloud may also encompass business relationships such as those between
../data/rfc/rfc5866.txt- network operators and third-party application providers. This
../data/rfc/rfc5866.txt: enables flexible intra- or inter-domain authorization, accounting,
../data/rfc/rfc5866.txt- and settlement.
../data/rfc/rfc5866.txt-
../data/rfc/rfc5866.txt-
../data/rfc/rfc5866.txt-
../data/rfc/rfc5866.txt-
--
../data/rfc/rfc5866.txt-
../data/rfc/rfc5866.txt- +-------------------------------------------------------+
../data/rfc/rfc5866.txt- | DIAMETER Client |
../data/rfc/rfc5866.txt- | Functionality |
../data/rfc/rfc5866.txt- | +---------------++-----------------++---------------+ |
../data/rfc/rfc5866.txt: | | User || QoS Application || Accounting | |
../data/rfc/rfc5866.txt- | | Authentication|| Client || Client (e.g., | |
../data/rfc/rfc5866.txt- | | Client || (Authorization ||for QoS Traffic| |
../data/rfc/rfc5866.txt- | +---------------+| of QoS Requests)|+---------------+ |
../data/rfc/rfc5866.txt- | +-----------------+ |
../data/rfc/rfc5866.txt- +-------------------------------------------------------+
--
../data/rfc/rfc5866.txt- authorized QoS parameters are set in the packet classifier and the
../data/rfc/rfc5866.txt- packet scheduler. Note that the parameters passed to the Traffic
../data/rfc/rfc5866.txt- Control function may be different from the ones that requested QoS
../data/rfc/rfc5866.txt- (depending on the authorization decision). Once the requested
../data/rfc/rfc5866.txt- resource is granted, the Resource Management function provides
../data/rfc/rfc5866.txt: accounting information to the AE via the Diameter client.
../data/rfc/rfc5866.txt-
../data/rfc/rfc5866.txt-3.2. Implications of Endpoint QoS Capabilities
../data/rfc/rfc5866.txt-
../data/rfc/rfc5866.txt-3.2.1. Endpoint Categories
../data/rfc/rfc5866.txt-
--
../data/rfc/rfc5866.txt- Bearer Gating
../data/rfc/rfc5866.txt- The Diameter QoS application MUST allow the AE to gate (i.e.,
../data/rfc/rfc5866.txt- enable/disable) authorized application flows based on, e.g.,
../data/rfc/rfc5866.txt- application state transitions.
../data/rfc/rfc5866.txt-
../data/rfc/rfc5866.txt: Accounting Records
../data/rfc/rfc5866.txt: The Diameter QoS application MAY define QoS accounting records
../data/rfc/rfc5866.txt- containing duration, volume (byte count) usage information, and a
../data/rfc/rfc5866.txt- description of the QoS attributes (e.g., bandwidth, delay, loss
../data/rfc/rfc5866.txt- rate) that were supported for the flow.
../data/rfc/rfc5866.txt-
../data/rfc/rfc5866.txt: Sending Accounting Records
../data/rfc/rfc5866.txt: The NE SHOULD be able to send accounting records for a particular
../data/rfc/rfc5866.txt: QoS reservation state to an accounting entity.
../data/rfc/rfc5866.txt-
../data/rfc/rfc5866.txt-
../data/rfc/rfc5866.txt-
../data/rfc/rfc5866.txt-
../data/rfc/rfc5866.txt-Sun, et al. Standards Track [Page 15]
--
../data/rfc/rfc5866.txt- Failure Notification
../data/rfc/rfc5866.txt- The Diameter QoS application MUST allow the NE to report failures,
../data/rfc/rfc5866.txt- such as loss of connectivity due to movement of a mobile node or
../data/rfc/rfc5866.txt- other reasons for packet loss, to the Authorizing Entity.
../data/rfc/rfc5866.txt-
../data/rfc/rfc5866.txt: Accounting Correlation
../data/rfc/rfc5866.txt- The Diameter QoS application MAY support the exchange of
../data/rfc/rfc5866.txt: sufficient information to allow for correlation between accounting
../data/rfc/rfc5866.txt: records generated by the NEs and accounting records generated by
../data/rfc/rfc5866.txt- an AppS.
../data/rfc/rfc5866.txt-
../data/rfc/rfc5866.txt- Interaction with Other AAA Applications
../data/rfc/rfc5866.txt- Interaction with other AAA applications, such as the Diameter
../data/rfc/rfc5866.txt- Network Access Server Application [RFC4005], may be required for
../data/rfc/rfc5866.txt: exchange of authorization, authentication, and accounting
../data/rfc/rfc5866.txt- information.
../data/rfc/rfc5866.txt-
../data/rfc/rfc5866.txt- In deployment scenarios where authentication of the QoS reservation
../data/rfc/rfc5866.txt- requesting entity (e.g., the user) is done by means outside the
../data/rfc/rfc5866.txt- Diameter QoS application protocol interaction, the AE is contacted
--
../data/rfc/rfc5866.txt- session that is used for the network access [RFC4005]. It is used
../data/rfc/rfc5866.txt- to tie the QoS authorization request to a prior authentication of
../data/rfc/rfc5866.txt- the end-host done by a co-located application for network access
../data/rfc/rfc5866.txt- authentication ([RFC4005]) at the QoS NE.
../data/rfc/rfc5866.txt-
../data/rfc/rfc5866.txt:8. Accounting
../data/rfc/rfc5866.txt-
../data/rfc/rfc5866.txt: An NE MAY start an accounting session by sending an Accounting-
../data/rfc/rfc5866.txt- Request (ACR) message after successful QoS reservation and activation
../data/rfc/rfc5866.txt- of the data flow (see Figures 6 and 7). After every successful re-
../data/rfc/rfc5866.txt- authorization procedure (see Figures 8 and 9), the NE MAY initiate an
../data/rfc/rfc5866.txt: interim accounting message exchange. After successful session
../data/rfc/rfc5866.txt- termination (see Figures 10 and 11), the NE may initiate a final
../data/rfc/rfc5866.txt: exchange of accounting messages for the termination of the accounting
../data/rfc/rfc5866.txt- session and report final records for the use of the QoS resources
../data/rfc/rfc5866.txt- reserved. It should be noted that the two sessions (authorization
../data/rfc/rfc5866.txt: and accounting) have independent management by the Diameter base
../data/rfc/rfc5866.txt: protocol, which allows for finalizing the accounting session after
../data/rfc/rfc5866.txt- the end of the authorization session.
../data/rfc/rfc5866.txt-
../data/rfc/rfc5866.txt: The detailed QoS accounting procedures are out of scope in this
../data/rfc/rfc5866.txt- document.
../data/rfc/rfc5866.txt-
../data/rfc/rfc5866.txt-
../data/rfc/rfc5866.txt-
../data/rfc/rfc5866.txt-
--
../data/rfc/rfc5887.txt- renumbering capability to well-scheduled renumbering events when the
../data/rfc/rfc5887.txt- mobile node is connected to its home agent and managed by the home
../data/rfc/rfc5887.txt- network administration. Unexpected home network renumbering events
../data/rfc/rfc5887.txt- when the mobile node is away from its home network and not connected
../data/rfc/rfc5887.txt- to the home agent are supported only if a relevant Authentication,
../data/rfc/rfc5887.txt: Authorisation, and Accounting (AAA) system is able to allocate
../data/rfc/rfc5887.txt- dynamically a home address and home agent for the mobile node.
../data/rfc/rfc5887.txt-
../data/rfc/rfc5887.txt-5.3.3. Multicast Issues
../data/rfc/rfc5887.txt-
../data/rfc/rfc5887.txt- As discussed in [THINK], IPv6 multicast can be used to help rather
--
../data/rfc/rfc5865.txt-
../data/rfc/rfc5865.txt-2.3. Recommendations on Implementation of an Admitted Telephony
../data/rfc/rfc5865.txt- Service Class
../data/rfc/rfc5865.txt-
../data/rfc/rfc5865.txt- When coupled with adequate Authentication, Authorization, and
../data/rfc/rfc5865.txt: Accounting (AAA) and capacity admission procedures as described in
../data/rfc/rfc5865.txt- Section 2.2, either of the two PHB implementations described in
../data/rfc/rfc5865.txt- Section 2.1 is sufficient to provide the services required for an
../data/rfc/rfc5865.txt- Admitted Telephony service class. If preemption is required, Section
../data/rfc/rfc5865.txt- 2.3.5.2 of [RFC4542] provides the tools for carrying out the
../data/rfc/rfc5865.txt- preemption. If preemption is not in view, or if used in addition to
--
../data/rfc/rfc2911.txt- automatically supplies the document name on behalf of the end
../data/rfc/rfc2911.txt- user by using a file name or an application generated name. If
../data/rfc/rfc2911.txt- this attribute is supplied, its value can be used in a manner
../data/rfc/rfc2911.txt- defined by each implementation. Examples include: printed
../data/rfc/rfc2911.txt- along with the Job (job start sheet, page adornments, etc.),
../data/rfc/rfc2911.txt: used by accounting or resource tracking management tools, or
../data/rfc/rfc2911.txt- even stored along with the document as a document level
../data/rfc/rfc2911.txt- attribute. IPP/1.1 does not support the concept of document
../data/rfc/rfc2911.txt- level attributes.
../data/rfc/rfc2911.txt-
../data/rfc/rfc2911.txt- "compression" (type3 keyword):
--
../data/rfc/rfc7256.txt- The formal specification of the behaviors associated with each of
../data/rfc/rfc7256.txt- these capabilities, singly and in combination, is given in Section 6.
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt- In addition to the multicast service processing behavior just
../data/rfc/rfc7256.txt- sketched, the definition of each capability includes support for the
../data/rfc/rfc7256.txt: multicast accounting and reporting services described in
../data/rfc/rfc7256.txt- Section 3.4.3 of [RFC5851]. Because of this common content and
../data/rfc/rfc7256.txt- because of other protocol overlaps between the different
../data/rfc/rfc7256.txt- capabilities, the protocol descriptions for the multicast extensions
../data/rfc/rfc7256.txt- specified in this document are merged into a single non-redundant
../data/rfc/rfc7256.txt- narrative. Tables in Section 6 then indicate the specific sub-
--
../data/rfc/rfc7256.txt- For the Multicast Replication Control message, these contents consist
../data/rfc/rfc7256.txt- of:
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt- o a Command Code field;
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt: o an Accounting field; and
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt- o an instance of the Multicast-Flow TLV.
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt- Figure 5 illustrates the complete Command TLV with the contents
../data/rfc/rfc7256.txt- specific to the Multicast Replication Control message.
--
../data/rfc/rfc7256.txt- 1 2 3
../data/rfc/rfc7256.txt- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
../data/rfc/rfc7256.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
../data/rfc/rfc7256.txt- | TLV Type = Command 0x0011 | Command TLV Length |
../data/rfc/rfc7256.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
../data/rfc/rfc7256.txt: |Command Code | Accounting | Reserved |
../data/rfc/rfc7256.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
../data/rfc/rfc7256.txt- | Multicast-Flow TLV |
../data/rfc/rfc7256.txt- | ... |
../data/rfc/rfc7256.txt- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
../data/rfc/rfc7256.txt- | Other embedded TLV Type | Other embedded TLV Length |
--
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt- 6 "Admission Control and Conditional Access Reject"
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt- Directives 4 through 6 are used as described in Section 4.4.2.
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt: o Accounting: Meaningful only when the Command Code is "Add" (1).
../data/rfc/rfc7256.txt: In that case, 0 indicates flow accounting is disabled, and 1
../data/rfc/rfc7256.txt: indicates that octet accounting for the flow is requested. The
../data/rfc/rfc7256.txt: sender MUST set the Accounting field to 0, and the receiver MUST
../data/rfc/rfc7256.txt: ignore the Accounting field for other Command Code values.
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt- o Reserved: Reserved for future use. MUST be set to zeroes by the
../data/rfc/rfc7256.txt- sender and ignored by the receiver.
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt- o Multicast-Flow TLV: An instance of the Multicast-Flow TLV
--
../data/rfc/rfc7256.txt- controlled or affected by attributes received in the Multicast
../data/rfc/rfc7256.txt- Replication Control message SHALL be as set by the last command or
../data/rfc/rfc7256.txt- message referring to that target and flow and containing the
../data/rfc/rfc7256.txt- controlling attribute. As an example, successive Multicast
../data/rfc/rfc7256.txt- Replication Control messages containing add commands for a given port
../data/rfc/rfc7256.txt: and flow but differing only in the Accounting field update the state
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt-Le Faucheur, et al. Standards Track [Page 21]
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt-RFC 7256 ANCP Multicast Extensions July 2014
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt: of the accounting feature to what is set in the final command
../data/rfc/rfc7256.txt- received, but all other features are unaffected by the second
../data/rfc/rfc7256.txt- message.
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt- If more than one Command TLV is present in a Multicast Replication
../data/rfc/rfc7256.txt- Control message, the AN MUST act on the commands in the order in
--
../data/rfc/rfc7256.txt- unique value, as described in Section 3.6.1.6 of [RFC6320].
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt- The AN MUST encode the Command TLV as specified in Section 4.3 with
../data/rfc/rfc7256.txt- the following additional rules:
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt: o The Accounting field MUST be set to 0.
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt- o The Command Code field MUST be set to "Add" (1) when the message
../data/rfc/rfc7256.txt- conveys a join request, to "Delete" (2) when the message conveys a
../data/rfc/rfc7256.txt- leave, and to "Delete All" (3) when the message conveys a leave of
../data/rfc/rfc7256.txt- all channels (on the target).
--
../data/rfc/rfc7256.txt- application of policies applicable to specific devices within the
../data/rfc/rfc7256.txt- customer's network. However, transmission of either of these fields
../data/rfc/rfc7256.txt- beyond the AN introduces potential privacy issues. Instead of
../data/rfc/rfc7256.txt- transmitting either of these identifiers, it is RECOMMENDED that the
../data/rfc/rfc7256.txt- AN map the required identifier to a local value known to the AN and
../data/rfc/rfc7256.txt: Authentication, Authorization, and Accounting (AAA) but not to the
../data/rfc/rfc7256.txt- NAS, as discussed in Section 8. The local identifier is transmitted
../data/rfc/rfc7256.txt- using the Request-Source-Device-Id TLV.
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt-4.4.2. Receiver Behavior
../data/rfc/rfc7256.txt-
--
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt-RFC 7256 ANCP Multicast Extensions July 2014
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt- * MUST contain the directive as accepted by the NAS. The NAS MAY
../data/rfc/rfc7256.txt: modify the Accounting field if flow accounting is required.
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt- o If the directive in the Multicast Admission Control message is
../data/rfc/rfc7256.txt- "Add" (1) and is processed correctly but not accepted by the NAS
../data/rfc/rfc7256.txt- (i.e., it does not pass the conditional access and admission
../data/rfc/rfc7256.txt- control check), the NAS MAY generate a Multicast Replication
--
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt- o a Command TLV containing:
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt- * Command Code = "Add" (1);
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt: * Accounting = "No" (0);
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt- * a Multicast-Flow embedded TLV indicating the multicast flow for
../data/rfc/rfc7256.txt- which the AN received the IGMP join: flow type "SSM" (2),
../data/rfc/rfc7256.txt- address family "IPv4" (1), Group address = 233.252.0.67, Source
../data/rfc/rfc7256.txt- Address = 192.0.2.21; and
--
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt- o a Command TLV containing:
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt- * Command Code = "Add" (1);
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt: * Accounting = "Yes" (1), since in our example the operator wants
../data/rfc/rfc7256.txt: accounting on this flow; and
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt- * a Multicast-Flow embedded TLV indicating the multicast flow
../data/rfc/rfc7256.txt- that the NAS is admitting for this access line: flow type "SSM"
../data/rfc/rfc7256.txt- (2), address family "IPv4" (1), Group address = 233.252.0.67,
../data/rfc/rfc7256.txt- Source Address = 192.0.2.21.
--
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt- o a Command TLV containing:
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt- * a Command Code = "Delete" (2);
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt: * Accounting = "No" (0);
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt- * a Multicast-Flow embedded TLV indicating the multicast flow for
../data/rfc/rfc7256.txt- which the AN received the IGMP leave: flow type "SSM" (2),
../data/rfc/rfc7256.txt- address family "IPv4" (1), Group address = 233.252.0.67, Source
../data/rfc/rfc7256.txt- Address = 192.0.2.21; and
--
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt- Figure 35: Enabling the Subscriber to Join an On-Line Game
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt- Message M2 terminating the flow when the subscriber leaves the game
../data/rfc/rfc7256.txt- looks the same as the message in Figure 35 with two exceptions: the
../data/rfc/rfc7256.txt: Command Code becomes "Delete" (2), and Accounting is set to "No" (0)
../data/rfc/rfc7256.txt: to turn off flow accounting. Of course, the Transaction Identifier
../data/rfc/rfc7256.txt- values will differ between the two messages.
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt-
../data/rfc/rfc7256.txt-
--
../data/rfc/rfc6312.txt- or in the Visited Network.
../data/rfc/rfc6312.txt-
../data/rfc/rfc6312.txt- o The Mobile Network Gateway (MNG): The MNG is the MN's default
../data/rfc/rfc6312.txt- router, which provides IP address management. The MNG performs
../data/rfc/rfc6312.txt- functions such as offering Quality of Service (QoS), applying
../data/rfc/rfc6312.txt: subscriber-specific policy, and enabling billing and accounting;
../data/rfc/rfc6312.txt- these functions are sometimes collectively referred to as
../data/rfc/rfc6312.txt- "subscriber-management" operations. The mobile network
../data/rfc/rfc6312.txt- architecture, as shown in Figure 1, defines the necessary protocol
../data/rfc/rfc6312.txt- interfaces to enable subscriber-management operations. The MNG is
../data/rfc/rfc6312.txt- typically located in the Home Network.
../data/rfc/rfc6312.txt-
../data/rfc/rfc6312.txt- o Border Router (BR): As the name implies, a BR borders the Internet
../data/rfc/rfc6312.txt- for the mobile network. The BR does not perform subscriber
../data/rfc/rfc6312.txt- management for the mobile network.
../data/rfc/rfc6312.txt-
../data/rfc/rfc6312.txt: o Authentication, Authorization, and Accounting (AAA): The general
../data/rfc/rfc6312.txt- functionality of AAA is used for subscriber authentication and
../data/rfc/rfc6312.txt- authorization for services as well as for generating billing and
../data/rfc/rfc6312.txt: accounting information.
../data/rfc/rfc6312.txt-
../data/rfc/rfc6312.txt- In 3GPP network environments, the subscriber authentication and
../data/rfc/rfc6312.txt- the subsequent authorization for connectivity and services is
../data/rfc/rfc6312.txt- provided using the "Home Location Register" (HLR) / "Home
../data/rfc/rfc6312.txt- Subscriber Server" (HSS) functionality.
--
../data/rfc/rfc6312.txt- functionality becomes important.
../data/rfc/rfc6312.txt-
../data/rfc/rfc6312.txt- In addition to the developments cited above, NAT placement is
../data/rfc/rfc6312.txt- important for other reasons as well. Access networks generally need
../data/rfc/rfc6312.txt- to produce network and service usage records for billing and
../data/rfc/rfc6312.txt: accounting. This is true also for mobile networks where "subscriber
../data/rfc/rfc6312.txt: management" features (i.e., QoS, Policy, and Billing and Accounting)
../data/rfc/rfc6312.txt- can be fairly detailed. Since a NAT introduces a binding between two
../data/rfc/rfc6312.txt- addresses, the bindings themselves become necessary information for
../data/rfc/rfc6312.txt- subscriber management. For instance, the offered QoS on private IPv4
../data/rfc/rfc6312.txt- address and the (shared) public IPv4 address may need to be
../data/rfc/rfc6312.txt: correlated for accounting purposes. As another example, the
../data/rfc/rfc6312.txt- Application Servers within the provider network may need to treat
../data/rfc/rfc6312.txt- traffic based on policy provided by the PCRF. If the IP address seen
../data/rfc/rfc6312.txt- by these Application Servers is not unique, the PCRF needs to be able
../data/rfc/rfc6312.txt- to inspect the NAT binding to disambiguate among the individual MNs.
../data/rfc/rfc6312.txt- The subscriber session management information and the service usage
--
../data/rfc/rfc7068.txt- [RFC6733] indicates that the sending client should attempt to send
../data/rfc/rfc7068.txt- the request to a different peer. It makes no suggestion that the
../data/rfc/rfc7068.txt- receipt of a DIAMETER_TOO_BUSY response should affect future Diameter
../data/rfc/rfc7068.txt- messages in any way.
../data/rfc/rfc7068.txt-
../data/rfc/rfc7068.txt: The Authentication, Authorization, and Accounting (AAA) Transport
../data/rfc/rfc7068.txt- Profile [RFC3539] recommends that a AAA node that receives a "Busy"
../data/rfc/rfc7068.txt- response failover all remaining requests to a different agent or
../data/rfc/rfc7068.txt- server. But while the Diameter base specification explicitly depends
../data/rfc/rfc7068.txt- on [RFC3539] to define transport behavior, it does not refer to
../data/rfc/rfc7068.txt- [RFC3539] in the description of behavior on receipt of a
--
../data/rfc/rfc7068.txt-
../data/rfc/rfc7068.txt- [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
../data/rfc/rfc7068.txt- RFC 2914, September 2000.
../data/rfc/rfc7068.txt-
../data/rfc/rfc7068.txt- [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
../data/rfc/rfc7068.txt: Accounting (AAA) Transport Profile", RFC 3539, June 2003.
../data/rfc/rfc7068.txt-
../data/rfc/rfc7068.txt-9.2. Informative References
../data/rfc/rfc7068.txt-
../data/rfc/rfc7068.txt- [RFC5390] Rosenberg, J., "Requirements for Management of Overload
../data/rfc/rfc7068.txt- in the Session Initiation Protocol", RFC 5390,
--
../data/rfc/rfc5836.txt- 0.1 to 0.00001 with a transfer delay of less than 300 ms. Any help
../data/rfc/rfc5836.txt- that an optimized handoff mechanism can provide toward meeting these
../data/rfc/rfc5836.txt- objectives is useful. The ultimate objective is to achieve seamless
../data/rfc/rfc5836.txt- handover with low latency, even when handover is between different
../data/rfc/rfc5836.txt- link technologies or between different Authentication, Authorization,
../data/rfc/rfc5836.txt: and Accounting (AAA) realms.
../data/rfc/rfc5836.txt-
../data/rfc/rfc5836.txt-
../data/rfc/rfc5836.txt-
../data/rfc/rfc5836.txt-
../data/rfc/rfc5836.txt-Ohba, et al. Informational [Page 3]
--
../data/rfc/rfc5836.txt-
../data/rfc/rfc5836.txt-2. Terminology
../data/rfc/rfc5836.txt-
../data/rfc/rfc5836.txt- AAA
../data/rfc/rfc5836.txt-
../data/rfc/rfc5836.txt: Authentication, Authorization, and Accounting (see below). RADIUS
../data/rfc/rfc5836.txt- [RFC2865] and Diameter [RFC3588] are examples of AAA protocols
../data/rfc/rfc5836.txt- defined in the IETF.
../data/rfc/rfc5836.txt-
../data/rfc/rfc5836.txt- AAA realm
../data/rfc/rfc5836.txt- The set of access networks within the scope of a specific AAA
../data/rfc/rfc5836.txt- server. Thus, if a mobile device moves from one attachment point
../data/rfc/rfc5836.txt- to another within the same AAA realm, it continues to be served by
../data/rfc/rfc5836.txt- the same AAA server.
../data/rfc/rfc5836.txt-
../data/rfc/rfc5836.txt: Accounting
../data/rfc/rfc5836.txt- The act of collecting information on resource usage for the
../data/rfc/rfc5836.txt- purpose of trend analysis, auditing, billing, or cost allocation
../data/rfc/rfc5836.txt- [RFC2989].
../data/rfc/rfc5836.txt-
../data/rfc/rfc5836.txt- Attachment Point
--
../data/rfc/rfc5836.txt- [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
../data/rfc/rfc5836.txt- Levkowetz, "Extensible Authentication Protocol (EAP)",
../data/rfc/rfc5836.txt- RFC 3748, June 2004.
../data/rfc/rfc5836.txt-
../data/rfc/rfc5836.txt- [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
../data/rfc/rfc5836.txt: Authorization, and Accounting (AAA) Key Management",
../data/rfc/rfc5836.txt- BCP 132, RFC 4962, July 2007.
../data/rfc/rfc5836.txt-
../data/rfc/rfc5836.txt- [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
../data/rfc/rfc5836.txt- Authentication Protocol (EAP) Key Management Framework",
../data/rfc/rfc5836.txt- RFC 5247, August 2008.
--
../data/rfc/rfc1102.txt- The Policy Terms, as described so far, do not permit the expression
../data/rfc/rfc1102.txt- of a realistic range of policies. What is needed is the ability to
../data/rfc/rfc1102.txt- attach to a Policy Term a number of conditions, which describe
../data/rfc/rfc1102.txt- circumstances under which the term is valid. These might include
../data/rfc/rfc1102.txt- what type of service (TOS) is available, what times of day the term
../data/rfc/rfc1102.txt: is valid, what accounting options are valid, and so on. A time-of-
../data/rfc/rfc1102.txt- day condition, for example, would permit networks, like time-sharing
../data/rfc/rfc1102.txt- systems, to offer their off-peak capacity to a wider community.
../data/rfc/rfc1102.txt-
../data/rfc/rfc1102.txt- In general, these conditions could be quite arbitrary. The important
../data/rfc/rfc1102.txt- constraint on these conditions is that any condition imposed by the
--
../data/rfc/rfc1102.txt-
../data/rfc/rfc1102.txt- Almost all of the existing Internet has been paid for as a capital
../data/rfc/rfc1102.txt- purchase and provided to the users as a free good. There are limited
../data/rfc/rfc1102.txt- examples of cost recovery, but these are based on an annual
../data/rfc/rfc1102.txt- subscription fee rather than a charge related to the utilization.
../data/rfc/rfc1102.txt: There is a growing body of opinion which says that accounting for
../data/rfc/rfc1102.txt- usage, if not billing for it, is an important component of effective
../data/rfc/rfc1102.txt: resource management. For this reason, tools for accounting and
../data/rfc/rfc1102.txt- billing must be a central part of any policy mechanism. However,
../data/rfc/rfc1102.txt- precisely because the administrative regions are autonomous, we
../data/rfc/rfc1102.txt- cannot impose a uniform form of billing policy on all of the regions.
../data/rfc/rfc1102.txt- Some of them may continue to provide service freely, or on the basis
../data/rfc/rfc1102.txt- of an annual fee. Others may charge on the basis of resources
--
../data/rfc/rfc1102.txt- flow. This solved the particular problem of tying together the
../data/rfc/rfc1102.txt- routing decision which had been made in each direction, so that they
../data/rfc/rfc1102.txt- could be used in the other. There are, in fact, a number of reasons
../data/rfc/rfc1102.txt- why the two halves of the flow should be tied together.
../data/rfc/rfc1102.txt-
../data/rfc/rfc1102.txt: - There is considerable overhead in accounting and collecting for the
../data/rfc/rfc1102.txt- usage. It is clearly desirable to have both halves of the flow
../data/rfc/rfc1102.txt- metered jointly.
../data/rfc/rfc1102.txt-
../data/rfc/rfc1102.txt- - If the route is not bi-directional, then a failure in the node
../data/rfc/rfc1102.txt- produces a uni-directional link. Uni-directional links are known
--
../data/rfc/rfc1102.txt-
../data/rfc/rfc1102.txt- An additional advantage of maintaining state in the gateway is that
../data/rfc/rfc1102.txt- it will greatly reduce the overhead of dealing with incoming packets.
../data/rfc/rfc1102.txt- There are a number of decisions which the Policy Gateway must make
../data/rfc/rfc1102.txt- which are a part of forwarding a packet: it must validate the Policy
../data/rfc/rfc1102.txt: Route against its terms, it must create or modify an accounting
../data/rfc/rfc1102.txt- record, and it must select the next Policy Gateway. It is
../data/rfc/rfc1102.txt- unreasonable to imagine performing these tasks from scratch for each
../data/rfc/rfc1102.txt- incoming packet. Once these decisions have been made, the results
../data/rfc/rfc1102.txt- should be cached, so that they can be used for subsequent packets.
../data/rfc/rfc1102.txt-
--
../data/rfc/rfc6192.txt-
../data/rfc/rfc6192.txt- o Permit Simple Network Management Protocol (SNMP) traffic from
../data/rfc/rfc6192.txt- network management stations within subnet 198.51.100.128/25 and
../data/rfc/rfc6192.txt- 2001:db8:100:3::/64
../data/rfc/rfc6192.txt-
../data/rfc/rfc6192.txt: o Permit RADIUS authentication and accounting replies from RADIUS
../data/rfc/rfc6192.txt- servers 198.51.100.9, 198.51.100.10, 2001:db8:100::9, and
../data/rfc/rfc6192.txt- 2001:db8:100::10 that are listening on UDP ports 1812 and 1813
../data/rfc/rfc6192.txt- (Internet Assigned Numbers Authority (IANA) RADIUS ports). Note
../data/rfc/rfc6192.txt- that this does not accommodate a server using the original UDP
../data/rfc/rfc6192.txt- ports of 1645 and 1646
Binary file ../data/rfc/rfc684.txt matches
--
../data/rfc/rfc5481.txt- 8.2. Measurement Devices .......................................32
../data/rfc/rfc5481.txt- 8.3. Units of Measurement ......................................33
../data/rfc/rfc5481.txt- 8.4. Test Duration .............................................33
../data/rfc/rfc5481.txt- 8.5. Clock Sync Options ........................................33
../data/rfc/rfc5481.txt- 8.6. Distinguishing Long Delay from Loss .......................34
../data/rfc/rfc5481.txt: 8.7. Accounting for Packet Reordering ..........................34
../data/rfc/rfc5481.txt- 8.8. Results Representation and Reporting ......................35
../data/rfc/rfc5481.txt- 9. Security Considerations ........................................35
../data/rfc/rfc5481.txt- 10. Acknowledgments ...............................................35
../data/rfc/rfc5481.txt- 11. Appendix on Calculating the D(min) in PDV .....................35
../data/rfc/rfc5481.txt- 12. References ....................................................36
--
../data/rfc/rfc5481.txt-
../data/rfc/rfc5481.txt- In essence, [IPPM-Reporting] suggests to use a long waiting time to
../data/rfc/rfc5481.txt- serve network characterization and revise results for specific
../data/rfc/rfc5481.txt- application delay thresholds as needed.
../data/rfc/rfc5481.txt-
../data/rfc/rfc5481.txt:8.7. Accounting for Packet Reordering
../data/rfc/rfc5481.txt-
../data/rfc/rfc5481.txt- Packet reordering, defined in [RFC4737], is essentially an extreme
../data/rfc/rfc5481.txt- form of delay variation where the packet stream arrival order differs
../data/rfc/rfc5481.txt- from the sending order.
../data/rfc/rfc5481.txt-
--
../data/rfc/rfc3315.txt- The information contained in the data area of this option is
../data/rfc/rfc3315.txt- contained in one or more opaque fields that represent the user class
../data/rfc/rfc3315.txt- or classes of which the client is a member. A server selects
../data/rfc/rfc3315.txt- configuration information for the client based on the classes
../data/rfc/rfc3315.txt- identified in this option. For example, the User Class option can be
../data/rfc/rfc3315.txt: used to configure all clients of people in the accounting department
../data/rfc/rfc3315.txt-
../data/rfc/rfc3315.txt-
../data/rfc/rfc3315.txt-
../data/rfc/rfc3315.txt-
../data/rfc/rfc3315.txt-Droms, et al. Standards Track [Page 84]
--
../data/rfc/rfc3702.txt-Category: Informational G. Camarillo
../data/rfc/rfc3702.txt- Ericsson
../data/rfc/rfc3702.txt- February 2004
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt: Authentication, Authorization, and Accounting
../data/rfc/rfc3702.txt- Requirements for the Session Initiation Protocol (SIP)
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-Status of this Memo
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt- This memo provides information for the Internet community. It does
--
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-Abstract
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt- As Session Initiation Protocol (SIP) services are deployed on the
../data/rfc/rfc3702.txt- Internet, there is a need for authentication, authorization, and
../data/rfc/rfc3702.txt: accounting of SIP sessions. This document sets out the basic
../data/rfc/rfc3702.txt- requirements for this work.
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-Table of Contents
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
--
../data/rfc/rfc3702.txt- 2.3.1. Ability to Authorize SIP Requests. . . . . . . . 7
../data/rfc/rfc3702.txt- 2.3.2. Information Transfer . . . . . . . . . . . . . . 7
../data/rfc/rfc3702.txt- 2.3.3. User De-authorization. . . . . . . . . . . . . . 7
../data/rfc/rfc3702.txt- 2.3.4. User Re-authorization. . . . . . . . . . . . . . 7
../data/rfc/rfc3702.txt- 2.3.5. Support for Credit Control . . . . . . . . . . . 7
../data/rfc/rfc3702.txt: 2.4. Accounting Requirements. . . . . . . . . . . . . . . . . 8
../data/rfc/rfc3702.txt: 2.4.1. Separation of Accounting Information . . . . . . 8
../data/rfc/rfc3702.txt: 2.4.2. Accounting Information Related to Session
../data/rfc/rfc3702.txt- Progression. . . . . . . . . . . . . . . . . . . 8
../data/rfc/rfc3702.txt: 2.4.3. Accounting Information Not Related to Session
../data/rfc/rfc3702.txt- Progression. . . . . . . . . . . . . . . . . . . 9
../data/rfc/rfc3702.txt- 2.4.4. Support for One-Time and Session-based
../data/rfc/rfc3702.txt: Accounting Records . . . . . . . . . . . . . . . 9
../data/rfc/rfc3702.txt: 2.4.5. Support for Accounting on Different Media
../data/rfc/rfc3702.txt- Components . . . . . . . . . . . . . . . . . . . 9
../data/rfc/rfc3702.txt: 2.4.6. Configuration of Accounting Generation
../data/rfc/rfc3702.txt- Parameters. . . . . . . . . . . . . . . . . . . 9
../data/rfc/rfc3702.txt- 2.4.7. Support for Arbitrary Correlations . . . . . . . 9
../data/rfc/rfc3702.txt- 3. Scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . 10
../data/rfc/rfc3702.txt- 3.1. WLAN Roaming Using Third Party Service Providers . . . . 11
../data/rfc/rfc3702.txt- 3.2. Conditional Authorization. . . . . . . . . . . . . . . . 12
--
../data/rfc/rfc3702.txt- 8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-1. Introduction
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt- The AAA working group is chartered to work on authentication,
../data/rfc/rfc3702.txt: authorization, and accounting solutions for the Internet. This work
../data/rfc/rfc3702.txt- consists of a base protocol, applications, end-to-end security
../data/rfc/rfc3702.txt- application, and a general architecture for providing these services
../data/rfc/rfc3702.txt- [3]. The AAA working group has specified applicability of AAA-based
../data/rfc/rfc3702.txt- solutions for a number of protocols (e.g., AAA requirements for
../data/rfc/rfc3702.txt- Mobile IP [4]).
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt- SIP is a signalling protocol for creating, modifying, and terminating
../data/rfc/rfc3702.txt- different types of sessions, such as Internet phone calls, multimedia
../data/rfc/rfc3702.txt- distribution, and multimedia conferences [1]. SIP sessions have
../data/rfc/rfc3702.txt: needs for session authentication, authorization, and accounting
../data/rfc/rfc3702.txt- (AAA).
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-
--
../data/rfc/rfc3702.txt- convenient for SIP entities to communicate with an AAA sever than to
../data/rfc/rfc3702.txt- attempt to store user credentials and profiles locally. SIP entities
../data/rfc/rfc3702.txt- use the SIP-AAA interface to access the AAA server.
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt- This document provides requirements for the interface between SIP
../data/rfc/rfc3702.txt: entities and AAA servers. While accounting requirements are
../data/rfc/rfc3702.txt- discussed, this document does not cover SIP charging or billing
../data/rfc/rfc3702.txt- mechanisms.
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt- One possible use of this document would be to create an AAA
../data/rfc/rfc3702.txt- application for SIP. Any protocol meeting the requirements outlined
--
../data/rfc/rfc3702.txt- 5. Section 2.3.4: RADIUS clients would need to support Dynamic
../data/rfc/rfc3702.txt- Authorization [7].
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-1.2. Terminology and Acronyms
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt: AAA: Authentication, Authorization, and Accounting
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt: Accounting: The collection of resource consumption data for the
../data/rfc/rfc3702.txt- purposes of capacity and trend analysis, cost allocation,
../data/rfc/rfc3702.txt: auditing, and billing. Accounting management requires that
../data/rfc/rfc3702.txt- resource consumption be measured, rated, assigned, and
../data/rfc/rfc3702.txt- communicated between appropriate parties [8].
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt: Accounting with credit control: The application checks the end user's
../data/rfc/rfc3702.txt- account for coverage for the requested service event charge
../data/rfc/rfc3702.txt- prior to execution of that service event.
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt- Home AAA Server: Server where user with which the user maintains an
../data/rfc/rfc3702.txt- account relationship.
--
../data/rfc/rfc3702.txt-2. Requirements
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt- In this section, we list the requirements. Protocol solutions are
../data/rfc/rfc3702.txt- not required to satisfy requirements for services that they do not
../data/rfc/rfc3702.txt- support. For example, a solution that provides authentication
../data/rfc/rfc3702.txt: services but not accounting services does not need to fulfill the
../data/rfc/rfc3702.txt: accounting requirements. It is expected that solutions will fulfill
../data/rfc/rfc3702.txt- the general requirements, plus the requirements for the specific
../data/rfc/rfc3702.txt- services they are providing.
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-
--
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt- Section 2.1 lists general requirements, Section 2.2 lists
../data/rfc/rfc3702.txt- requirements related to authentication, Section 2.3 lists
../data/rfc/rfc3702.txt- requirements related to authorization, and Section 2.4 lists
../data/rfc/rfc3702.txt: requirements related to accounting.
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-2.1. Common Requirements
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt- This section outlines general requirements on the SIP-AAA interface.
../data/rfc/rfc3702.txt-
--
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-2.1.6. SIP Session Changes
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt- The SIP-AAA interface MUST allow a SIP entity to inform the AAA
../data/rfc/rfc3702.txt- server about changes in the SIP session that may affect the
../data/rfc/rfc3702.txt: authorization, authentication, or accounting for that SIP session.
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-2.1.7. Reliable Transfer of Protocol Messages
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt- The SIP-AAA interface SHOULD provide a reliable transfer of AAA
../data/rfc/rfc3702.txt- protocol messages between the SIP entity and the AAA server.
--
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt- The SIP-AAA interface MUST support credit control. That is, the AAA
../data/rfc/rfc3702.txt- server has to be able to check the end user's account for coverage
../data/rfc/rfc3702.txt- for the requested service event charge before authorizing execution
../data/rfc/rfc3702.txt- of that service event. Note that this requirement is related to
../data/rfc/rfc3702.txt: accounting as well.
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-Loughney & Camarillo Informational [Page 7]
../data/rfc/rfc3702.txt-
--
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt- Credit control is useful to implement prepaid services where all
../data/rfc/rfc3702.txt- chargeable events related to a specific account are withheld from the
../data/rfc/rfc3702.txt- end user when the credit of that account is exhausted or expired.
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt:2.4. Accounting Requirements
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt- This section outlines requirements on the SIP-AAA interface related
../data/rfc/rfc3702.txt: to accounting. Accounting is more than simple charging. Accounting
../data/rfc/rfc3702.txt- may be a simple list of services accessed, servers accessed, duration
../data/rfc/rfc3702.txt- of session, etc. Charging for SIP sessions can be extremely complex
../data/rfc/rfc3702.txt- and requires some additional study. It is not the intent of this
../data/rfc/rfc3702.txt- section to focus on charging.
../data/rfc/rfc3702.txt-
--
../data/rfc/rfc3702.txt- transfer a wide range of data, some SIP nodes may not have access
../data/rfc/rfc3702.txt- to it. In order to design a network, it is important to analyze
../data/rfc/rfc3702.txt- which SIP nodes will be able to generate the desired account
../data/rfc/rfc3702.txt- records.
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt:2.4.1. Separation of Accounting Information
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt: AAA accounting messages MUST be able to provide granular information
../data/rfc/rfc3702.txt- based on different parameters.
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt- For example, it should be possible to separate "session duration"
../data/rfc/rfc3702.txt- information from other information generated via additional services
../data/rfc/rfc3702.txt: (e.g., 3-way calling). Separating accounting information makes it
../data/rfc/rfc3702.txt: possible to provide accounting information to different parties based
../data/rfc/rfc3702.txt- upon different aspects of the session.
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt:2.4.2. Accounting Information Related to Session Progression
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt: There MUST be support in the SIP-AAA interface for accounting
../data/rfc/rfc3702.txt: transfers where the information contained in the accounting data has
../data/rfc/rfc3702.txt- a direct bearing on the establishment, progression, and termination
../data/rfc/rfc3702.txt- of a session (e.g., reception of a BYE request).
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-
--
../data/rfc/rfc3702.txt-Loughney & Camarillo Informational [Page 8]
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-RFC 3702 AAA Requirements for SIP February 2004
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt:2.4.3. Accounting Information Not Related to Session Progression
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt: There MUST be support in the SIP-AAA interface for accounting
../data/rfc/rfc3702.txt: transfers where the information contained in the accounting data does
../data/rfc/rfc3702.txt- NOT have a direct bearing on the establishment, progression, and
../data/rfc/rfc3702.txt- termination of a session (e.g., an instant MESSAGE that is not
../data/rfc/rfc3702.txt- related to any session).
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt:2.4.4. Support for One-Time and Session-based Accounting Records
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt- The SIP-AAA interface MUST allow SIP servers to provide relevant
../data/rfc/rfc3702.txt: accounting information for billing and inter-network settlement
../data/rfc/rfc3702.txt: purposes to the AAA servers. Both one-time event accounting records
../data/rfc/rfc3702.txt: and session based (START, INTERIM, STOP records) accounting MUST be
../data/rfc/rfc3702.txt- supported.
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt:2.4.5. Support for Accounting on Different Media Components
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt: The SIP-AAA interface MUST support accounting per media component
../data/rfc/rfc3702.txt- (e.g., voice and video). That is, the SIP-AAA interface MUST be able
../data/rfc/rfc3702.txt- to provide the AAA server with the types (e.g., voice and video) of
../data/rfc/rfc3702.txt- the media streams of a given session.
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt- Note, however, that some SIP entities do not have access to this
--
../data/rfc/rfc3702.txt- (e.g., a gateway towards the PSTN).
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt- The SIP-AAA interface MUST enable different parties to be charged per
../data/rfc/rfc3702.txt- media component.
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt:2.4.6. Configuration of Accounting Generation Parameters
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt- The SIP-AAA interface MUST allow AAA servers to communicate
../data/rfc/rfc3702.txt: parameters for accounting generation.
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-2.4.7. Support for Arbitrary Correlations
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt: Some networks need to be able to relate accounting information to
../data/rfc/rfc3702.txt- some aspect of the SIP messages involved. So, the SIP-AAA interface
../data/rfc/rfc3702.txt- MUST allow the AAA server to correlate a particular AAA session with
../data/rfc/rfc3702.txt- any aspect of the SIP messages. For example, an AAA server that
../data/rfc/rfc3702.txt: receives accounting information about a SIP dialog may be interested
../data/rfc/rfc3702.txt- in knowing the Call-ID of the SIP dialog.
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-
--
../data/rfc/rfc3702.txt- | | | |
../data/rfc/rfc3702.txt- | |<------OK--------| |
../data/rfc/rfc3702.txt- | | | |
../data/rfc/rfc3702.txt- | |---------INVITE------------------>|
../data/rfc/rfc3702.txt- | | | |
../data/rfc/rfc3702.txt: | |-Accounting msg->| |
../data/rfc/rfc3702.txt- | | | |
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt- Figure 2: WLAN roaming user
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt- User A accesses the Internet using a WLAN access outside his home
--
../data/rfc/rfc3702.txt- (Proxy Authentication Required) response, and user A reissues the
../data/rfc/rfc3702.txt- INVITE including his credentials. SIP proxy C consults user A's home
../data/rfc/rfc3702.txt- AAA server, which confirms that the credentials belong to user A and
../data/rfc/rfc3702.txt- that SIP proxy C can go ahead and provide its service for that call.
../data/rfc/rfc3702.txt- SIP proxy C routes the INVITE forward towards user B and sends an
../data/rfc/rfc3702.txt: accounting message to the AAA server, which will be used later to
../data/rfc/rfc3702.txt- charge user A for the service provided by SIP proxy C.
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-
--
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt- [3] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko,
../data/rfc/rfc3702.txt- "Diameter Base Protocol", RFC 3588, September 2003.
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt- [4] Glass, S., Hiller, T., Jacobs, S. and C. Perkins, "Mobile IP
../data/rfc/rfc3702.txt: Authentication, Authorization, and Accounting Requirements", RFC
../data/rfc/rfc3702.txt- 2977, October 2000.
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt- [5] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
../data/rfc/rfc3702.txt- Authentication Dial in User Service (RADIUS)", RFC 2865, June
../data/rfc/rfc3702.txt- 2000.
--
../data/rfc/rfc3702.txt- [7] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba,
../data/rfc/rfc3702.txt- "Dynamic Authorization Extensions to Remote Authentication Dial
../data/rfc/rfc3702.txt- in User Service (RADIUS)", RFC 3576, July 2003.
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt- [8] Aboba, B., Arkko, J. and D. Harrington, "Introduction to
../data/rfc/rfc3702.txt: Accounting Management", RFC 2975, October 2000.
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-
../data/rfc/rfc3702.txt-
--
../data/rfc/rfc6245.txt- keys in both directions. The GRE key assignment in the FA and the HA
../data/rfc/rfc6245.txt- is outside the scope of this memo.
../data/rfc/rfc6245.txt-
../data/rfc/rfc6245.txt- The GRE Key Extension SHALL follow the format defined in [RFC5944].
../data/rfc/rfc6245.txt- This extension SHALL be added after the MN-HA and MN-FA Challenge and
../data/rfc/rfc6245.txt: MN-AAA (Mobile Node - Authentication, Authorization, and Accounting)
../data/rfc/rfc6245.txt- extensions (if any) and before the FA-HA Auth extension (if any).
../data/rfc/rfc6245.txt-
../data/rfc/rfc6245.txt-4.2. Home Agent Requirements for GRE Tunneling Support
../data/rfc/rfc6245.txt-
../data/rfc/rfc6245.txt- The HA MUST follow the procedures specified in [RFC5944] in
--
../data/rfc/rfc1167.txt- support the general operation of the system (for example, network
../data/rfc/rfc1167.txt- management facilities, name servers of various types, email, database
../data/rfc/rfc1167.txt- and other kinds of information servers, multicast routers,
../data/rfc/rfc1167.txt- cryptographic certificate servers) and collaboration support tools
../data/rfc/rfc1167.txt- including video/teleconferencing systems and other "groupware"
../data/rfc/rfc1167.txt: facilities. Accounting and access control mechanisms will be
../data/rfc/rfc1167.txt- required.
../data/rfc/rfc1167.txt-
../data/rfc/rfc1167.txt- 7. The system will support multiple protocols on an end to end basis.
../data/rfc/rfc1167.txt- At the least, full TCP/IP and OSI protocol stacks will be supported.
../data/rfc/rfc1167.txt- Dealing with Connectionless and Connection-Oriented Network Services
--
../data/rfc/rfc1167.txt- network in the U.S. with its local and inter-exchange carrier (IEC)
../data/rfc/rfc1167.txt- structure. It should be noted that in the presence of the local and
../data/rfc/rfc1167.txt- IEC structure, it has proven possible to support private and virtual
../data/rfc/rfc1167.txt- private networking as well. The same needs to be true of the NREN.
../data/rfc/rfc1167.txt-
../data/rfc/rfc1167.txt: A critical element of any commercial service is accounting and
../data/rfc/rfc1167.txt- billing. It must be possible to identify users (billable parties,
../data/rfc/rfc1167.txt- anyway) and to compute usage charges. This is not to say that the
../data/rfc/rfc1167.txt- NREN component networks must necessarily bill on the basis of usage.
../data/rfc/rfc1167.txt- It may prove preferable to have fixed access charges which might be
../data/rfc/rfc1167.txt- modulated by access data rate, as some of the intermediate-level
--
../data/rfc/rfc1167.txt- Even if such an activity is initiated through federal action, it may
../data/rfc/rfc1167.txt- be helpful, in the long run, if it eventually embraces a much wider
../data/rfc/rfc1167.txt- community.
../data/rfc/rfc1167.txt-
../data/rfc/rfc1167.txt- Agreements are needed on the technical foundations for network
../data/rfc/rfc1167.txt: monitoring and management, for internetwork accounting and exchange
../data/rfc/rfc1167.txt- payments, for problem identification, tracking, escalation and
../data/rfc/rfc1167.txt- resolution. A framework is needed for the support of users of the
../data/rfc/rfc1167.txt- aggregate NREN. This suggests cooperative agreements among network
../data/rfc/rfc1167.txt- information centers, user service and support organizations to begin
../data/rfc/rfc1167.txt- with. Eventually, the cost of such operations will have to be
--
../data/rfc/rfc5281.txt-
../data/rfc/rfc5281.txt-4. Terminology
../data/rfc/rfc5281.txt-
../data/rfc/rfc5281.txt- AAA
../data/rfc/rfc5281.txt-
../data/rfc/rfc5281.txt: Authentication, Authorization, and Accounting - functions that are
../data/rfc/rfc5281.txt- generally required to control access to a network and support
../data/rfc/rfc5281.txt- billing and auditing.
../data/rfc/rfc5281.txt-
../data/rfc/rfc5281.txt- AAA protocol
../data/rfc/rfc5281.txt-
--
../data/rfc/rfc5281.txt- AAA server
../data/rfc/rfc5281.txt-
../data/rfc/rfc5281.txt- A server which performs one or more AAA functions: authenticating
../data/rfc/rfc5281.txt- a user prior to granting network service, providing authorization
../data/rfc/rfc5281.txt- (policy) information governing the type of network service the
../data/rfc/rfc5281.txt: user is to be granted, and accumulating accounting information
../data/rfc/rfc5281.txt- about actual usage.
../data/rfc/rfc5281.txt-
../data/rfc/rfc5281.txt- AAA/H
../data/rfc/rfc5281.txt-
../data/rfc/rfc5281.txt- A AAA server in the user's home domain, where authentication and
--
../data/rfc/rfc5281.txt-
../data/rfc/rfc5281.txt- During phase 2, the TLS record layer is used to tunnel information
../data/rfc/rfc5281.txt- between client and TTLS server to perform any of a number of
../data/rfc/rfc5281.txt- functions. These might include user authentication, client integrity
../data/rfc/rfc5281.txt- validation, negotiation of data communication security capabilities,
../data/rfc/rfc5281.txt: key distribution, communication of accounting information, etc.
../data/rfc/rfc5281.txt- Information between client and TTLS server is exchanged via
../data/rfc/rfc5281.txt- attribute-value pairs (AVPs) compatible with RADIUS and Diameter;
../data/rfc/rfc5281.txt- thus, any type of function that can be implemented via such AVPs may
../data/rfc/rfc5281.txt- easily be performed.
../data/rfc/rfc5281.txt-
--
../data/rfc/rfc5281.txt- Session-Id = 0x15 || client.random || server.random
../data/rfc/rfc5281.txt-
../data/rfc/rfc5281.txt-12.2. Peer-Id
../data/rfc/rfc5281.txt-
../data/rfc/rfc5281.txt- The Peer-Id represents the identity to be used for access control and
../data/rfc/rfc5281.txt: accounting purposes. When the client presents a certificate as part
../data/rfc/rfc5281.txt- of the TLS handshake, the Peer-Id is determined based on information
../data/rfc/rfc5281.txt- in the certificate, as specified in Section 5.2 of [RFC5216].
../data/rfc/rfc5281.txt- Otherwise, the Peer-Id is null.
../data/rfc/rfc5281.txt-
../data/rfc/rfc5281.txt-12.3. Server-Id
--
../data/rfc/rfc2504.txt- comes from an unknown source to a computer storing business records,
../data/rfc/rfc2504.txt- other valuable data and data which is potentially damaging if the
../data/rfc/rfc2504.txt- information was lost or stolen.
../data/rfc/rfc2504.txt-
../data/rfc/rfc2504.txt- If the system has a mixed purpose, say recreation, correspondence
../data/rfc/rfc2504.txt: and some home accounting, perhaps you will hazard some downloading of
../data/rfc/rfc2504.txt- software. You unavoidably take some risk of acquiring stuff
../data/rfc/rfc2504.txt- which is not exactly what it seems to be.
../data/rfc/rfc2504.txt-
../data/rfc/rfc2504.txt- It may be worthwhile installing privacy software on a computer if it
../data/rfc/rfc2504.txt- is shared by multiple users. That way, a friend of a room mate won't
--
../data/rfc/rfc3571.txt-
../data/rfc/rfc3571.txt-2.2. Normal Operations
../data/rfc/rfc3571.txt-
../data/rfc/rfc3571.txt-2.2.1. Connection Establishment and Initial Configuration Request
../data/rfc/rfc3571.txt-
../data/rfc/rfc3571.txt: The Accounting Timer object in the COPS Connection Accept message
../data/rfc/rfc3571.txt- contains the minimum number of seconds between reporting intervals as
../data/rfc/rfc3571.txt- described in [COPS] and [FEEDBACKFWK]. This is used as the basic
../data/rfc/rfc3571.txt- unit of measurement in defining intervals for specific usage policies
../data/rfc/rfc3571.txt- with the frwkFeedbackLinkInterval attribute.
../data/rfc/rfc3571.txt-
--
../data/rfc/rfc3571.txt- operate with the installed policy. When the locally installed policy
../data/rfc/rfc3571.txt- at the PEP expires, the usage policy data also expires.
../data/rfc/rfc3571.txt-
../data/rfc/rfc3571.txt- Upon successful reconnection where the PEP is still caching policy,
../data/rfc/rfc3571.txt- the PDP indicates to the PEP that the PEP may resume sending of the
../data/rfc/rfc3571.txt: COPS accounting type report messages. The PDP does this by issuing
../data/rfc/rfc3571.txt- an unsolicited decision containing the frwkFeedbackResumeIndicator
../data/rfc/rfc3571.txt- set to 'resume'. The PEP should resume reporting at the next
../data/rfc/rfc3571.txt- appropriate feedback interval established upon the acceptance of the
../data/rfc/rfc3571.txt- re-connection. The PDP is aware of the request state Handle(s) and
../data/rfc/rfc3571.txt-
--
../data/rfc/rfc3571.txt- This class links the selection criteria instance with the usage
../data/rfc/rfc3571.txt- class. This table permits the reuse of a selection criteria instance
../data/rfc/rfc3571.txt- for multiple usage policies.
../data/rfc/rfc3571.txt-
../data/rfc/rfc3571.txt- The linkage table also permits the definition of a maximum reporting
../data/rfc/rfc3571.txt: interval to use when issuing the COPS accounting type reports for the
../data/rfc/rfc3571.txt- usage instance. A value of 0 in this attribute indicates that the
../data/rfc/rfc3571.txt- usage policy must be solicited.
../data/rfc/rfc3571.txt-
../data/rfc/rfc3571.txt-3.3.5. Feedback Traffic Statistics Threshold
../data/rfc/rfc3571.txt-
--
../data/rfc/rfc3571.txt- solicitReport(4)
../data/rfc/rfc3571.txt- }
../data/rfc/rfc3571.txt- STATUS current
../data/rfc/rfc3571.txt- DESCRIPTION
../data/rfc/rfc3571.txt- "The value indicates if the PEP is to send cached
../data/rfc/rfc3571.txt: usage policies via COPS accounting type report
../data/rfc/rfc3571.txt- messages.
../data/rfc/rfc3571.txt- The enumeration values are:
../data/rfc/rfc3571.txt- (1) suspendMonitoringAndReports
../data/rfc/rfc3571.txt- (2) suspendReports
../data/rfc/rfc3571.txt- (3) resume
--
../data/rfc/rfc3571.txt- frwkFeedbackLinkInterval OBJECT-TYPE
../data/rfc/rfc3571.txt- SYNTAX Integer32
../data/rfc/rfc3571.txt- STATUS current
../data/rfc/rfc3571.txt- DESCRIPTION
../data/rfc/rfc3571.txt- "Maximum interval in units of the value of the
../data/rfc/rfc3571.txt: Accounting Timer specified by the PDP in the client
../data/rfc/rfc3571.txt- accept message. A frwkFeedbackLinkInterval of 1 is
../data/rfc/rfc3571.txt: equal to the value of the Accounting Timer. This value
../data/rfc/rfc3571.txt- must be 1 or greater. "
../data/rfc/rfc3571.txt-
../data/rfc/rfc3571.txt- ::= { frwkFeedbackLinkEntry 4}
../data/rfc/rfc3571.txt-
../data/rfc/rfc3571.txt- frwkFeedbackLinkThreshold OBJECT-TYPE
--
../data/rfc/rfc2800.txt-WEBDAV HTTP Extensions for Distributed Authoring -- WEBDAV 2518
../data/rfc/rfc2800.txt-ATM-MIBMAN Definitions of Managed Objects for ATM Management 2515
../data/rfc/rfc2800.txt-ATM-TC-OID Definitions of Textual Conventions and OBJECT- 2514
../data/rfc/rfc2800.txt- IDENTITIES for ATM Management
../data/rfc/rfc2800.txt--------- Managed Objects for Controlling the Collection 2513
../data/rfc/rfc2800.txt: and Storage of Accounting Information for
../data/rfc/rfc2800.txt- Connection-Oriented Networks
../data/rfc/rfc2800.txt:-------- Accounting Information for ATM Networks 2512
../data/rfc/rfc2800.txt-X.509-CRMF Internet X.509 Certificate Request Message Format 2511
../data/rfc/rfc2800.txt-PKICMP Internet X.509 Public Key Infrastructure Certificate 2510
../data/rfc/rfc2800.txt- Management Protocols
../data/rfc/rfc2800.txt-IPCOM-PPP IP Header Compression over PPP 2509
../data/rfc/rfc2800.txt--------- Compressing IP/UDP/RTP Headers for Low-Speed Serial 2508
--
../data/rfc/rfc2297.txt- channel connection is specified by its input port, input VPI, and
../data/rfc/rfc2297.txt- input VCI. Each virtual path connection is specified by its input
../data/rfc/rfc2297.txt- port and input VPI. These are specified in the Input Port, Input VPI,
../data/rfc/rfc2297.txt- and Input VCI fields of each Activity Record. Two forms of activity
../data/rfc/rfc2297.txt- detection are supported. If the switch supports per connection
../data/rfc/rfc2297.txt: traffic accounting, the current value of the traffic counter for each
../data/rfc/rfc2297.txt- specified virtual channel connection or virtual path connection must
../data/rfc/rfc2297.txt- be returned. The units of traffic counted are not specified but will
../data/rfc/rfc2297.txt- typically be either cells or frames. The controller must compare the
../data/rfc/rfc2297.txt- traffic counts returned in the message with previous values for each
../data/rfc/rfc2297.txt- of the specified connections to determine whether each connection has
../data/rfc/rfc2297.txt- been active in the intervening period. If the switch does not
../data/rfc/rfc2297.txt: support per connection traffic accounting, but is capable of
../data/rfc/rfc2297.txt- detecting per connection activity by some other unspecified means,
../data/rfc/rfc2297.txt- the result may be indicated for each connection using the Flags
../data/rfc/rfc2297.txt- field. The Connection Activity message is:
../data/rfc/rfc2297.txt-
../data/rfc/rfc2297.txt- Message Type = 48
--
../data/rfc/rfc8321.txt- also be used in a Service Function Chaining (SFC) domain. Lastly,
../data/rfc/rfc8321.txt- the application of the marking method to Network Virtualization
../data/rfc/rfc8321.txt- over Layer 3 (NVO3) protocols is considered by [NVO3-ENCAPS].
../data/rfc/rfc8321.txt-
../data/rfc/rfc8321.txt- o MPLS Performance Measurement: RFC 6374 [RFC6374] uses the Loss
../data/rfc/rfc8321.txt: Measurement (LM) packet as the packet accounting demarcation
../data/rfc/rfc8321.txt- point. Unfortunately, this gives rise to a number of problems
../data/rfc/rfc8321.txt: that may lead to significant packet accounting errors in certain
../data/rfc/rfc8321.txt- situations. [MPLS-FLOW] discusses the desired capabilities for
../data/rfc/rfc8321.txt-
../data/rfc/rfc8321.txt-
../data/rfc/rfc8321.txt-
../data/rfc/rfc8321.txt-Fioccola, et al. Experimental [Page 21]
--
../data/rfc/rfc6827.txt- 2. Routing Areas, OSPF Areas, and Protocol Instances ...............5
../data/rfc/rfc6827.txt- 3. Terminology and Identification ..................................6
../data/rfc/rfc6827.txt- 4. Reachability ....................................................7
../data/rfc/rfc6827.txt- 5. Link Attribute ..................................................8
../data/rfc/rfc6827.txt- 5.1. Local Adaptation ...........................................8
../data/rfc/rfc6827.txt: 5.2. Bandwidth Accounting .......................................9
../data/rfc/rfc6827.txt- 6. Routing Information Scope .......................................9
../data/rfc/rfc6827.txt- 6.1. Link Advertisement (Local and Remote TE Router ID Sub-TLV) .9
../data/rfc/rfc6827.txt- 6.2. Reachability Advertisement (Local TE Router ID Sub-TLV) ...11
../data/rfc/rfc6827.txt- 7. Routing Information Dissemination ..............................11
../data/rfc/rfc6827.txt- 7.1. Import/Export Rules .......................................12
--
../data/rfc/rfc6827.txt-Malis, et al. Standards Track [Page 8]
../data/rfc/rfc6827.txt-
../data/rfc/rfc6827.txt-RFC 6827 ASON Routing for OSPFv2 Protocols January 2013
../data/rfc/rfc6827.txt-
../data/rfc/rfc6827.txt-
../data/rfc/rfc6827.txt:5.2. Bandwidth Accounting
../data/rfc/rfc6827.txt-
../data/rfc/rfc6827.txt- GMPLS routing defines an ISCD that provides, among other things, the
../data/rfc/rfc6827.txt- quantities of the maximum/minimum available bandwidth per priority
../data/rfc/rfc6827.txt- for Label Switched Paths (LSPs). One or more ISCD sub-TLVs can be
../data/rfc/rfc6827.txt- associated with an interface, per [RFC4202] and [RFC4203]. This
../data/rfc/rfc6827.txt- information, combined with the Unreserved Bandwidth Link TLV sub-TLV
../data/rfc/rfc6827.txt: [RFC3630], provides the basis for bandwidth accounting.
../data/rfc/rfc6827.txt-
../data/rfc/rfc6827.txt- In the ASON context, additional information may be included when the
../data/rfc/rfc6827.txt- representation and information in the other advertised fields are not
../data/rfc/rfc6827.txt- sufficient for a specific technology, e.g., SDH. The definition of
../data/rfc/rfc6827.txt- technology-specific information elements is beyond the scope of this
--
../data/rfc/rfc6827.txt-
../data/rfc/rfc6827.txt- Management plane: performs management functions for the transport
../data/rfc/rfc6827.txt- plane, the control plane, and the system as a whole. It also
../data/rfc/rfc6827.txt- provides coordination between all the planes. The following
../data/rfc/rfc6827.txt- management functional areas are performed in the management plane:
../data/rfc/rfc6827.txt: performance, fault, configuration, accounting, and security
../data/rfc/rfc6827.txt- management.
../data/rfc/rfc6827.txt-
../data/rfc/rfc6827.txt- Management domain: (See Recommendation G.805.) A management domain
../data/rfc/rfc6827.txt- defines a collection of managed objects that are grouped to meet
../data/rfc/rfc6827.txt- organizational requirements according to geography, technology,
../data/rfc/rfc6827.txt- policy, or other structure, and for a number of functional areas
../data/rfc/rfc6827.txt: such as Fault, Configuration, Accounting, Performance, and
../data/rfc/rfc6827.txt- Security (FCAPS), for the purpose of providing control in a
../data/rfc/rfc6827.txt- consistent manner. Management domains can be disjoint, contained,
../data/rfc/rfc6827.txt-
../data/rfc/rfc6827.txt-
../data/rfc/rfc6827.txt-
--
../data/rfc/rfc3846.txt-
../data/rfc/rfc3846.txt-Abstract
../data/rfc/rfc3846.txt-
../data/rfc/rfc3846.txt- When a mobile node moves between two foreign networks, it has to be
../data/rfc/rfc3846.txt- re-authenticated. If the home network has both multiple
../data/rfc/rfc3846.txt: Authentication Authorization and Accounting (AAA) servers and Home
../data/rfc/rfc3846.txt- Agents (HAs) in use, the Home AAA server may not have sufficient
../data/rfc/rfc3846.txt- information to process the re-authentication correctly (i.e., to
../data/rfc/rfc3846.txt- ensure that the same HA continues to be used). This document defines
../data/rfc/rfc3846.txt- a Mobile IP extension that carries identities for the Home AAA and HA
../data/rfc/rfc3846.txt- servers in the form of Network Access Identifiers (NAIs). The
--
../data/rfc/rfc5580.txt- 2. Terminology .....................................................3
../data/rfc/rfc5580.txt- 3. Delivery Methods for Location Information .......................3
../data/rfc/rfc5580.txt- 3.1. Location Delivery Based on Out-of-Band Agreements ..........4
../data/rfc/rfc5580.txt- 3.2. Location Delivery Based on Initial Request .................5
../data/rfc/rfc5580.txt- 3.3. Location Delivery Based on Mid-Session Request .............6
../data/rfc/rfc5580.txt: 3.4. Location Delivery in Accounting Messages ..................10
../data/rfc/rfc5580.txt- 4. Attributes .....................................................11
../data/rfc/rfc5580.txt- 4.1. Operator-Name Attribute ...................................12
../data/rfc/rfc5580.txt- 4.2. Location-Information Attribute ............................14
../data/rfc/rfc5580.txt- 4.3. Location-Data Attribute ...................................16
../data/rfc/rfc5580.txt- 4.3.1. Civic Location Profile .............................17
--
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt-1. Introduction
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt- This document defines attributes within RADIUS and Diameter that can
../data/rfc/rfc5580.txt- be used to convey location-related information within authentication
../data/rfc/rfc5580.txt: and accounting exchanges.
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt- Location information may be useful in a number of scenarios.
../data/rfc/rfc5580.txt- Wireless networks (including wireless LAN) are being deployed in
../data/rfc/rfc5580.txt- public places such as airports, hotels, shopping malls, and coffee
../data/rfc/rfc5580.txt- shops by a diverse set of operators such as cellular network
--
../data/rfc/rfc5580.txt- server responds with either an Access-Accept or an Access-Reject
../data/rfc/rfc5580.txt- message.
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt- The use of dynamic authorization [RFC5176] is necessary when location
../data/rfc/rfc5580.txt- information is needed on-demand and cannot be obtained from
../data/rfc/rfc5580.txt: accounting information in a timely fashion.
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt- Figure 3 shows the above-described approach graphically.
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt- +---------------+ +---------------+ +------+
../data/rfc/rfc5580.txt- | Dynamic | | Dynamic | |RADIUS|
--
../data/rfc/rfc5580.txt- : <<Further exchanges later>> : :
../data/rfc/rfc5580.txt- : : :
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt- Figure 4: Location Delivery Based on CoA
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt:3.4. Location Delivery in Accounting Messages
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt: Location information may also be reported in accounting messages.
../data/rfc/rfc5580.txt: Accounting messages are generated when the session starts, when the
../data/rfc/rfc5580.txt- session stops, and periodically during the lifetime of the session.
../data/rfc/rfc5580.txt: Accounting messages may also be generated when the user roams during
../data/rfc/rfc5580.txt- handoff.
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt: Accounting information may be needed by the billing system to
../data/rfc/rfc5580.txt- calculate the user's bill. For example, there may be different
../data/rfc/rfc5580.txt- tariffs or tax rates applied based on the location.
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt- If the RADIUS server needs to obtain location information in
../data/rfc/rfc5580.txt: accounting messages, then it needs to include a Requested-Location-
../data/rfc/rfc5580.txt- Info Attribute with the Access-Accept message. The Basic-Location-
../data/rfc/rfc5580.txt- Policy-Rules and the Extended-Location-Policy-Rules Attributes are to
../data/rfc/rfc5580.txt: be echoed in the Accounting-Request if indicated in the Access-
../data/rfc/rfc5580.txt- Accept.
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt- Figure 5 shows the message exchange.
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt-
--
../data/rfc/rfc5580.txt- | |<---------------------------------|
../data/rfc/rfc5580.txt- | Authentication | |
../data/rfc/rfc5580.txt- | Success | |
../data/rfc/rfc5580.txt- |<----------------------| |
../data/rfc/rfc5580.txt- | | |
../data/rfc/rfc5580.txt: | | Accounting-Request |
../data/rfc/rfc5580.txt- | | + Location-Information |
../data/rfc/rfc5580.txt- | | + Location-Data |
../data/rfc/rfc5580.txt- | | + Basic-Location-Policy-Rules |
../data/rfc/rfc5580.txt- | | + Extended-Location-Policy-Rules|
../data/rfc/rfc5580.txt- | |--------------------------------->|
../data/rfc/rfc5580.txt- | | |
../data/rfc/rfc5580.txt: | | Accounting-Response |
../data/rfc/rfc5580.txt- | |<---------------------------------|
../data/rfc/rfc5580.txt- | | |
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt: Figure 5: Location Delivery in Accounting Messages
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt-4. Attributes
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt- It is important to note that the location-specific parts of the
../data/rfc/rfc5580.txt- attributes defined below are not meant to be processed by the RADIUS
--
../data/rfc/rfc5580.txt- identifier to uniquely identify the owner of an access network. The
../data/rfc/rfc5580.txt- value of the Operator-Name is a non-NULL terminated text whose length
../data/rfc/rfc5580.txt- MUST NOT exceed 253 bytes.
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt- The Operator-Name Attribute SHOULD be sent in Access-Request and
../data/rfc/rfc5580.txt: Accounting-Request messages where the Acc-Status-Type is set to
../data/rfc/rfc5580.txt- Start, Interim, or Stop.
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt- A summary of the Operator-Name Attribute is shown below.
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt- 0 1 2 3
--
../data/rfc/rfc5580.txt- ASCII characters containing the ICC itself.
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt-4.2. Location-Information Attribute
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt- The Location-Information Attribute MAY be sent in the Access-Request
../data/rfc/rfc5580.txt: message, the Accounting-Request message, both of these messages, or
../data/rfc/rfc5580.txt: no message. For the Accounting-Request message, the Acc-Status-Type
../data/rfc/rfc5580.txt- may be set to Start, Interim, or Stop.
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt- The Location-Information Attribute provides meta-data about the
../data/rfc/rfc5580.txt- location information, such as sighting time, time-to-live, location-
../data/rfc/rfc5580.txt- determination method, etc.
--
../data/rfc/rfc5580.txt- octets.
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt-4.3. Location-Data Attribute
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt- The Location-Data Attribute MAY be sent in Access-Request and
../data/rfc/rfc5580.txt: Accounting-Request messages. For the Accounting-Request message, the
../data/rfc/rfc5580.txt- Acc-Status-Type may be set to Start, Interim, or Stop.
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt- The format is shown below.
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt- 0 1 2 3
--
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt-4.4. Basic-Location-Policy-Rules Attribute
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt- The Basic-Location-Policy-Rules Attribute MAY be sent in Access-
../data/rfc/rfc5580.txt- Request, Access-Accept, Access-Challenge, Change-of-Authorization,
../data/rfc/rfc5580.txt: and Accounting-Request messages.
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt- Policy rules control the distribution of location information. In
../data/rfc/rfc5580.txt- order to understand and process the Basic-Location-Policy-Rules
../data/rfc/rfc5580.txt- Attribute, RADIUS clients are obligated to utilize a default value of
../data/rfc/rfc5580.txt- Basic-Location-Policy-Rules, unless explicitly configured otherwise,
--
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt-4.5. Extended-Location-Policy-Rules Attribute
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt- The Extended-Location-Policy-Rules Attribute MAY be sent in Access-
../data/rfc/rfc5580.txt- Request, Access-Accept, Access-Challenge, Access-Reject, Change-of-
../data/rfc/rfc5580.txt: Authorization, and Accounting-Request messages.
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt- The Ruleset Reference field of this attribute is of variable length.
../data/rfc/rfc5580.txt- It contains a URI that indicates where the richer ruleset can be
../data/rfc/rfc5580.txt- found. This URI SHOULD use the HTTPS URI scheme. As a deviation
../data/rfc/rfc5580.txt- from [RFC4119], this field only contains a reference and does not
--
../data/rfc/rfc5580.txt- Location-Info Attribute), then the RADIUS server may respond with
../data/rfc/rfc5580.txt- an Access-Reject message with an Error-Cause Attribute (including
../data/rfc/rfc5580.txt- the "Location-Info-Required" value).
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt- o If the RADIUS server would like location information in the
../data/rfc/rfc5580.txt: Accounting-Request message but does not require it for computing
../data/rfc/rfc5580.txt- an authorization decision, then the Access-Accept message MUST
../data/rfc/rfc5580.txt- include a Required-Info Attribute. This is typically the case
../data/rfc/rfc5580.txt- when location information is used only for billing. The RADIUS
../data/rfc/rfc5580.txt- client SHOULD attach location information, if available, to the
../data/rfc/rfc5580.txt: Accounting-Request (unless authorization policies dictate
../data/rfc/rfc5580.txt- something different).
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt- If the RADIUS server does not send a Requested-Location-Info
../data/rfc/rfc5580.txt- Attribute, then the RADIUS client MUST NOT attach location
../data/rfc/rfc5580.txt- information to messages towards the RADIUS server. The user's
--
../data/rfc/rfc5580.txt-Tschofenig, et al. Standards Track [Page 28]
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt-RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt: Request Accept Reject Challenge Accounting # Attribute
../data/rfc/rfc5580.txt- Request
../data/rfc/rfc5580.txt- 0-1 0-1 0 0 0+ 126 Operator-Name
../data/rfc/rfc5580.txt- 0+ 0 0 0 0+ 127 Location-Information
../data/rfc/rfc5580.txt- 0+ 0 0 0 0+ 128 Location-Data
../data/rfc/rfc5580.txt- 0-1 0-1 0-1 0-1 0-1 129 Basic-Location-
--
../data/rfc/rfc5580.txt-Tschofenig, et al. Standards Track [Page 30]
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt-RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt: What is said about Accounting-Request applies in Diameter to
../data/rfc/rfc5580.txt: Accounting-Request [RFC4005] as well.
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt- Note that these AVPs may be used by Diameter applications other than
../data/rfc/rfc5580.txt- RFC 4005 [RFC4005] and RFC 4072 [RFC4072]. The above-mentioned
../data/rfc/rfc5580.txt- applications are, however, likely to be relevant in the context of
../data/rfc/rfc5580.txt- this document.
--
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt- o RADIUS may return information from the home network to the visited
../data/rfc/rfc5580.txt- one in a manner that makes it possible to either identify the user
../data/rfc/rfc5580.txt- or at least correlate his session with other sessions, such as the
../data/rfc/rfc5580.txt- use of static data in a Class Attribute [RFC2865] or in some
../data/rfc/rfc5580.txt: accounting attribute usage scenarios [RFC4372].
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt- o Mobility protocols may reveal some long-term identifier, such as a
../data/rfc/rfc5580.txt- home address.
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt- o Application-layer protocols may reveal other permanent
--
../data/rfc/rfc5580.txt- Specification, Implementation", RFC 1305, March 1992.
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt- [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
../data/rfc/rfc5580.txt- Protocol (CHAP)", RFC 1994, August 1996.
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc5580.txt-
../data/rfc/rfc5580.txt- [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote
../data/rfc/rfc5580.txt- Authentication Dial In User Service) Support For
../data/rfc/rfc5580.txt- Extensible Authentication Protocol (EAP)", RFC 3579,
../data/rfc/rfc5580.txt- September 2003.
--
../data/rfc/rfc7962.txt- (https://openwireless.org/) also promotes the sharing of private
../data/rfc/rfc7962.txt- wireless networks.
../data/rfc/rfc7962.txt-
../data/rfc/rfc7962.txt- Some companies [Fon] also promote the use of Wi-Fi routers with dual
../data/rfc/rfc7962.txt- access: a Wi-Fi network for the user and a shared one. Adequate
../data/rfc/rfc7962.txt: Authentication, Authorization, and Accounting (AAA) policies are
../data/rfc/rfc7962.txt- implemented, so people can join the network in different ways: they
../data/rfc/rfc7962.txt- can buy a router, so they can share their connection and in turn,
../data/rfc/rfc7962.txt- they get access to all the routers associated with the community.
../data/rfc/rfc7962.txt- Some users can even get some revenue every time another user connects
../data/rfc/rfc7962.txt- to their Wi-Fi Access Point. Users that are not part of the
--
../data/rfc/rfc2566.txt- the Job name. Typically, the client software automatically
../data/rfc/rfc2566.txt- supplies the document name on behalf of the end user by using a
../data/rfc/rfc2566.txt- file name or an application generated name. If this attribute
../data/rfc/rfc2566.txt- is supplied, its value can be used in a manner defined by each
../data/rfc/rfc2566.txt- implementation. Examples include: printed along with the Job
../data/rfc/rfc2566.txt: (job start sheet, page adornments, etc.), used by accounting or
../data/rfc/rfc2566.txt- resource tracking management tools, or even stored along with
../data/rfc/rfc2566.txt- the document as a document level attribute. IPP/1.0 does not
../data/rfc/rfc2566.txt- support the concept of document level attributes.
../data/rfc/rfc2566.txt-
../data/rfc/rfc2566.txt-
--
../data/rfc/rfc3769.txt- transmission of the delegated prefixes to the customer.
../data/rfc/rfc3769.txt-
../data/rfc/rfc3769.txt- The prefix delegation should provide for reliable authentication of
../data/rfc/rfc3769.txt- the identity of the service provider's edge router.
../data/rfc/rfc3769.txt-
../data/rfc/rfc3769.txt:3.7. Accounting
../data/rfc/rfc3769.txt-
../data/rfc/rfc3769.txt- The prefix delegation mechanism must allow for the ISP to obtain
../data/rfc/rfc3769.txt: accounting information about delegated prefixes from the PE.
../data/rfc/rfc3769.txt-
../data/rfc/rfc3769.txt-3.8. Hardware technology Considerations
../data/rfc/rfc3769.txt-
../data/rfc/rfc3769.txt- The prefix delegation mechanism should work on any hardware link
../data/rfc/rfc3769.txt- technology between the PE and the CPE and should be hardware
--
../data/rfc/rfc6733.txt- Diameter Base Protocol
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-Abstract
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- The Diameter base protocol is intended to provide an Authentication,
../data/rfc/rfc6733.txt: Authorization, and Accounting (AAA) framework for applications such
../data/rfc/rfc6733.txt- as network access or IP mobility in both local and roaming
../data/rfc/rfc6733.txt- situations. This document specifies the message format, transport,
../data/rfc/rfc6733.txt: error reporting, accounting, and security services used by all
../data/rfc/rfc6733.txt- Diameter applications. The Diameter base protocol as defined in this
../data/rfc/rfc6733.txt- document obsoletes RFC 3588 and RFC 5719, and it must be supported by
../data/rfc/rfc6733.txt- all new Diameter implementations.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-Status of This Memo
--
../data/rfc/rfc6733.txt- 7.5. Failed-AVP AVP ............................................96
../data/rfc/rfc6733.txt- 7.6. Experimental-Result AVP ...................................97
../data/rfc/rfc6733.txt- 7.7. Experimental-Result-Code AVP ..............................97
../data/rfc/rfc6733.txt- 8. Diameter User Sessions .........................................98
../data/rfc/rfc6733.txt- 8.1. Authorization Session State Machine .......................99
../data/rfc/rfc6733.txt: 8.2. Accounting Session State Machine .........................104
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
--
../data/rfc/rfc6733.txt- 8.17. Session-Binding AVP .....................................120
../data/rfc/rfc6733.txt- 8.18. Session-Server-Failover AVP .............................121
../data/rfc/rfc6733.txt- 8.19. Multi-Round-Time-Out AVP ................................122
../data/rfc/rfc6733.txt- 8.20. Class AVP ...............................................122
../data/rfc/rfc6733.txt- 8.21. Event-Timestamp AVP .....................................122
../data/rfc/rfc6733.txt: 9. Accounting ....................................................123
../data/rfc/rfc6733.txt- 9.1. Server Directed Model ....................................123
../data/rfc/rfc6733.txt- 9.2. Protocol Messages ........................................124
../data/rfc/rfc6733.txt: 9.3. Accounting Application Extension and Requirements ........124
../data/rfc/rfc6733.txt- 9.4. Fault Resilience .........................................125
../data/rfc/rfc6733.txt: 9.5. Accounting Records .......................................125
../data/rfc/rfc6733.txt: 9.6. Correlation of Accounting Records ........................126
../data/rfc/rfc6733.txt: 9.7. Accounting Command Codes .................................127
../data/rfc/rfc6733.txt: 9.7.1. Accounting-Request ................................127
../data/rfc/rfc6733.txt: 9.7.2. Accounting-Answer .................................128
../data/rfc/rfc6733.txt: 9.8. Accounting AVPs ..........................................129
../data/rfc/rfc6733.txt: 9.8.1. Accounting-Record-Type AVP ........................129
../data/rfc/rfc6733.txt- 9.8.2. Acct-Interim-Interval AVP .........................130
../data/rfc/rfc6733.txt: 9.8.3. Accounting-Record-Number AVP ......................131
../data/rfc/rfc6733.txt- 9.8.4. Acct-Session-Id AVP ...............................131
../data/rfc/rfc6733.txt- 9.8.5. Acct-Multi-Session-Id AVP .........................131
../data/rfc/rfc6733.txt: 9.8.6. Accounting-Sub-Session-Id AVP .....................131
../data/rfc/rfc6733.txt: 9.8.7. Accounting-Realtime-Required AVP ..................132
../data/rfc/rfc6733.txt- 10. AVP Occurrence Tables ........................................132
../data/rfc/rfc6733.txt- 10.1. Base Protocol Command AVP Table .........................133
../data/rfc/rfc6733.txt: 10.2. Accounting AVP Table ....................................134
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
--
../data/rfc/rfc6733.txt- 11.2.1. Command Codes ....................................136
../data/rfc/rfc6733.txt- 11.2.2. Command Flags ....................................137
../data/rfc/rfc6733.txt- 11.3. AVP Values ..............................................137
../data/rfc/rfc6733.txt- 11.3.1. Experimental-Result-Code AVP .....................137
../data/rfc/rfc6733.txt- 11.3.2. Result-Code AVP Values ...........................137
../data/rfc/rfc6733.txt: 11.3.3. Accounting-Record-Type AVP Values ................137
../data/rfc/rfc6733.txt- 11.3.4. Termination-Cause AVP Values .....................137
../data/rfc/rfc6733.txt- 11.3.5. Redirect-Host-Usage AVP Values ...................137
../data/rfc/rfc6733.txt- 11.3.6. Session-Server-Failover AVP Values ...............137
../data/rfc/rfc6733.txt- 11.3.7. Session-Binding AVP Values .......................137
../data/rfc/rfc6733.txt- 11.3.8. Disconnect-Cause AVP Values ......................138
../data/rfc/rfc6733.txt- 11.3.9. Auth-Request-Type AVP Values .....................138
../data/rfc/rfc6733.txt- 11.3.10. Auth-Session-State AVP Values ...................138
../data/rfc/rfc6733.txt- 11.3.11. Re-Auth-Request-Type AVP Values .................138
../data/rfc/rfc6733.txt: 11.3.12. Accounting-Realtime-Required AVP Values .........138
../data/rfc/rfc6733.txt- 11.3.13. Inband-Security-Id AVP (code 299) ...............138
../data/rfc/rfc6733.txt- 11.4. _diameters Service Name and Port Number Registration ....138
../data/rfc/rfc6733.txt- 11.5. SCTP Payload Protocol Identifiers .......................139
../data/rfc/rfc6733.txt- 11.6. S-NAPTR Parameters ......................................139
../data/rfc/rfc6733.txt- 12. Diameter Protocol-Related Configurable Parameters ............139
--
../data/rfc/rfc6733.txt-RFC 6733 Diameter Base Protocol October 2012
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-1. Introduction
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: Authentication, Authorization, and Accounting (AAA) protocols such as
../data/rfc/rfc6733.txt- TACACS [RFC1492] and RADIUS [RFC2865] were initially deployed to
../data/rfc/rfc6733.txt- provide dial-up PPP [RFC1661] and terminal server access. Over time,
../data/rfc/rfc6733.txt- AAA support was needed on many new access technologies, the scale and
../data/rfc/rfc6733.txt- complexity of AAA networks grew, and AAA was also used on new
../data/rfc/rfc6733.txt- applications (such as voice over IP). This led to new demands on AAA
--
../data/rfc/rfc6733.txt- integrity scheme that is required only for use with response
../data/rfc/rfc6733.txt- packets. While [RFC2869] defines an additional authentication and
../data/rfc/rfc6733.txt- integrity mechanism, use is only required during Extensible
../data/rfc/rfc6733.txt- Authentication Protocol (EAP) [RFC3748] sessions. While attribute
../data/rfc/rfc6733.txt- hiding is supported, [RFC2865] does not provide support for per-
../data/rfc/rfc6733.txt: packet confidentiality. In accounting, [RFC2866] assumes that
../data/rfc/rfc6733.txt- replay protection is provided by the backend billing server rather
../data/rfc/rfc6733.txt- than within the protocol itself.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- While [RFC3162] defines the use of IPsec with RADIUS, support for
../data/rfc/rfc6733.txt- IPsec is not required. In order to provide universal support for
--
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Reliable transport
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- RADIUS runs over UDP, and does not define retransmission behavior;
../data/rfc/rfc6733.txt- as a result, reliability varies between implementations. As
../data/rfc/rfc6733.txt: described in [RFC2975], this is a major issue in accounting, where
../data/rfc/rfc6733.txt- packet loss may translate directly into revenue loss. In order to
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
--
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- o Extensibility, required in [RFC2989], through addition of new
../data/rfc/rfc6733.txt- applications, commands, and AVPs
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- o Basic services necessary for applications, such as the handling of
../data/rfc/rfc6733.txt: user sessions or accounting
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- All data delivered by the protocol is in the form of AVPs. Some of
../data/rfc/rfc6733.txt- these AVP values are used by the Diameter protocol itself, while
../data/rfc/rfc6733.txt- others deliver data associated with particular applications that
../data/rfc/rfc6733.txt- employ Diameter. AVPs may be arbitrarily added to Diameter messages,
--
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-RFC 6733 Diameter Base Protocol October 2012
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- o Exchanging resource usage information, which may be used for
../data/rfc/rfc6733.txt: accounting purposes, capacity planning, etc.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- o Routing, relaying, proxying, and redirecting of Diameter messages
../data/rfc/rfc6733.txt- through a server hierarchy
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- The Diameter base protocol satisfies the minimum requirements for a
../data/rfc/rfc6733.txt- AAA protocol, as specified by [RFC2989]. The base protocol may be
../data/rfc/rfc6733.txt: used by itself for accounting purposes only, or it may be used with a
../data/rfc/rfc6733.txt- Diameter application, such as Mobile IPv4 [RFC4004], or network
../data/rfc/rfc6733.txt- access [RFC4005]. It is also possible for the base protocol to be
../data/rfc/rfc6733.txt- extended for use in new applications, via the addition of new
../data/rfc/rfc6733.txt- commands or AVPs. The initial focus of Diameter was network access
../data/rfc/rfc6733.txt: and accounting applications. A truly generic AAA protocol used by
../data/rfc/rfc6733.txt- many applications might provide functionality not provided by
../data/rfc/rfc6733.txt- Diameter. Therefore, it is imperative that the designers of new
../data/rfc/rfc6733.txt- applications understand their requirements before using Diameter.
../data/rfc/rfc6733.txt- See Section 1.3.4 for more information on Diameter applications.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Any node can initiate a request. In that sense, Diameter is a peer-
../data/rfc/rfc6733.txt- to-peer protocol. In this document, a Diameter client is a device at
../data/rfc/rfc6733.txt- the edge of the network that performs access control, such as a
../data/rfc/rfc6733.txt- Network Access Server (NAS) or a Foreign Agent (FA). A Diameter
../data/rfc/rfc6733.txt- client generates Diameter messages to request authentication,
../data/rfc/rfc6733.txt: authorization, and accounting services for the user. A Diameter
../data/rfc/rfc6733.txt- agent is a node that does not provide local user authentication or
../data/rfc/rfc6733.txt- authorization services; agents include proxies, redirects, and relay
../data/rfc/rfc6733.txt- agents. A Diameter server performs authentication and/or
../data/rfc/rfc6733.txt- authorization of the user. A Diameter node may act as an agent for
../data/rfc/rfc6733.txt- certain requests while acting as a server for others.
--
../data/rfc/rfc6733.txt- [RFC3539]. This document obsoletes both RFC 3588 and RFC 5719. A
../data/rfc/rfc6733.txt- summary of the base protocol updates included in this document can be
../data/rfc/rfc6733.txt- found in Section 1.1.3.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- This document defines the base protocol specification for AAA, which
../data/rfc/rfc6733.txt: includes support for accounting. There are also a myriad of
../data/rfc/rfc6733.txt- applications documents describing applications that use this base
../data/rfc/rfc6733.txt: specification for Authentication, Authorization, and Accounting.
../data/rfc/rfc6733.txt- These application documents specify how to use the Diameter protocol
../data/rfc/rfc6733.txt- within the context of their application.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
--
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-1.2. Terminology
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- AAA
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: Authentication, Authorization, and Accounting.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
--
../data/rfc/rfc6733.txt- Augmented Backus-Naur Form [RFC5234]. A metalanguage with its own
../data/rfc/rfc6733.txt- formal syntax and rules. It is based on the Backus-Naur Form and
../data/rfc/rfc6733.txt- is used to define message exchanges in a bi-directional
../data/rfc/rfc6733.txt- communications protocol.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: Accounting
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- The act of collecting information on resource usage for the
../data/rfc/rfc6733.txt- purpose of capacity planning, auditing, billing, or cost
../data/rfc/rfc6733.txt- allocation.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: Accounting Record
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: An accounting record represents a summary of the resource
../data/rfc/rfc6733.txt: consumption of a user over the entire session. Accounting servers
../data/rfc/rfc6733.txt: creating the accounting record may do so by processing interim
../data/rfc/rfc6733.txt: accounting events or accounting events from several devices
../data/rfc/rfc6733.txt- serving the same user.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Authentication
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- The act of verifying the identity of an entity (subject).
--
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- The Diameter protocol consists of a header followed by one or more
../data/rfc/rfc6733.txt- Attribute-Value-Pairs (AVPs). An AVP includes a header and is
../data/rfc/rfc6733.txt- used to encapsulate protocol-specific data (e.g., routing
../data/rfc/rfc6733.txt- information) as well as authentication, authorization, or
../data/rfc/rfc6733.txt: accounting information.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Command Code Format (CCF)
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- A modified form of ABNF used to define Diameter commands (see
../data/rfc/rfc6733.txt- Section 3.2).
--
../data/rfc/rfc6733.txt- connection are called Diameter peers.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Diameter Server
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- A Diameter server is a Diameter node that handles authentication,
../data/rfc/rfc6733.txt: authorization, and accounting requests for a particular realm. By
../data/rfc/rfc6733.txt- its very nature, a Diameter server must support Diameter server
../data/rfc/rfc6733.txt- applications in addition to the base protocol.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Downstream
../data/rfc/rfc6733.txt-
--
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Home Server
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- A Diameter server that serves the Home Realm.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: Interim Accounting
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: An interim accounting message provides a snapshot of usage during
../data/rfc/rfc6733.txt- a user's session. Typically, it is implemented in order to
../data/rfc/rfc6733.txt: provide for partial accounting of a user's session in case a
../data/rfc/rfc6733.txt- device reboot or other network problem prevents the delivery of a
../data/rfc/rfc6733.txt- session summary message or session record.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
--
../data/rfc/rfc6733.txt-Fajardo, et al. Standards Track [Page 15]
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-RFC 6733 Diameter Base Protocol October 2012
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: Real-Time Accounting
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: Real-time accounting involves the processing of information on
../data/rfc/rfc6733.txt- resource usage within a defined time window. Typically, time
../data/rfc/rfc6733.txt- constraints are imposed in order to limit financial risk. The
../data/rfc/rfc6733.txt- Diameter Credit-Control Application [RFC4006] is an example of an
../data/rfc/rfc6733.txt: application that defines real-time accounting functionality.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Relay Agent or Relay
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Relays forward requests and responses based on routing-related
../data/rfc/rfc6733.txt- AVPs and routing table entries. Since relays do not make policy
--
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- A sub-session represents a distinct service (e.g., QoS or data
../data/rfc/rfc6733.txt- characteristics) provided to a given session. These services may
../data/rfc/rfc6733.txt- happen concurrently (e.g., simultaneous voice and data transfer
../data/rfc/rfc6733.txt- during the same session) or serially. These changes in sessions
../data/rfc/rfc6733.txt: are tracked with the Accounting-Sub-Session-Id.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Transaction State
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- The Diameter protocol requires that agents maintain transaction
../data/rfc/rfc6733.txt- state, which is used for failover purposes. Transaction state
--
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-RFC 6733 Diameter Base Protocol October 2012
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- From the point of view of extensibility, Diameter authentication,
../data/rfc/rfc6733.txt: authorization, and accounting applications are treated in the same
../data/rfc/rfc6733.txt- way.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Note: Protocol designers should try to reuse existing functionality,
../data/rfc/rfc6733.txt- namely AVP values, AVPs, commands, and Diameter applications. Reuse
../data/rfc/rfc6733.txt- simplifies standardization and implementation. To avoid potential
--
../data/rfc/rfc6733.txt- receipt of the Session-Termination-Request, Session-Termination-
../data/rfc/rfc6733.txt- Answer, expiration of authorized service time in the Session-Timeout
../data/rfc/rfc6733.txt- AVP, and according to rules established in a particular Diameter
../data/rfc/rfc6733.txt- application.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: The base Diameter protocol may be used by itself for accounting
../data/rfc/rfc6733.txt- applications. For authentication and authorization, it is always
../data/rfc/rfc6733.txt- extended for a particular application.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Diameter clients MUST support the base protocol, which includes
../data/rfc/rfc6733.txt: accounting. In addition, they MUST fully support each Diameter
../data/rfc/rfc6733.txt- application that is needed to implement the client's service, e.g.,
../data/rfc/rfc6733.txt- Network Access Server Requirements (NASREQ) [RFC2881] and/or Mobile
../data/rfc/rfc6733.txt- IPv4. A Diameter client MUST be referred to as "Diameter X Client"
../data/rfc/rfc6733.txt- where X is the application that it supports and not a "Diameter
../data/rfc/rfc6733.txt- Client".
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Diameter servers MUST support the base protocol, which includes
../data/rfc/rfc6733.txt: accounting. In addition, they MUST fully support each Diameter
../data/rfc/rfc6733.txt- application that is needed to implement the intended service, e.g.,
../data/rfc/rfc6733.txt- NASREQ and/or Mobile IPv4. A Diameter server MUST be referred to as
../data/rfc/rfc6733.txt- "Diameter X Server" where X is the application that it supports, and
../data/rfc/rfc6733.txt- not a "Diameter Server".
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Diameter relays and redirect agents are transparent to the Diameter
../data/rfc/rfc6733.txt- applications, but they MUST support the Diameter base protocol, which
../data/rfc/rfc6733.txt: includes accounting, and all Diameter applications.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Diameter proxies MUST support the base protocol, which includes
../data/rfc/rfc6733.txt: accounting. In addition, they MUST fully support each Diameter
../data/rfc/rfc6733.txt- application that is needed to implement proxied services, e.g.,
../data/rfc/rfc6733.txt- NASREQ and/or Mobile IPv4. A Diameter proxy MUST be referred to as
../data/rfc/rfc6733.txt- "Diameter X Proxy" where X is the application which it supports, and
../data/rfc/rfc6733.txt- not a "Diameter Proxy".
../data/rfc/rfc6733.txt-
--
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- The following Application Id values are defined:
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Diameter common message 0
../data/rfc/rfc6733.txt: Diameter base accounting 3
../data/rfc/rfc6733.txt- Relay 0xffffffff
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Relay and redirect agents MUST advertise the Relay Application ID,
../data/rfc/rfc6733.txt- while all other Diameter nodes MUST advertise locally supported
../data/rfc/rfc6733.txt- applications. The receiver of a Capabilities Exchange message
--
../data/rfc/rfc6733.txt- transaction as specified by any contractual relationship between the
../data/rfc/rfc6733.txt- server and the previous hop. A DIAMETER_AUTHORIZATION_REJECTED error
../data/rfc/rfc6733.txt- message (see Section 7.1.5) is sent if the route traversed by the
../data/rfc/rfc6733.txt- request is unacceptable.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: A home realm may also wish to check that each accounting request
../data/rfc/rfc6733.txt- message corresponds to a Diameter response authorizing the session.
../data/rfc/rfc6733.txt: Accounting requests without corresponding authorization responses
../data/rfc/rfc6733.txt: SHOULD be subjected to further scrutiny, as should accounting
../data/rfc/rfc6733.txt- requests indicating a difference between the requested and provided
../data/rfc/rfc6733.txt- service.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Forwarding of an authorization response is considered evidence of a
../data/rfc/rfc6733.txt- willingness to take on financial risk relative to the session. A
--
../data/rfc/rfc6733.txt-Fajardo, et al. Standards Track [Page 33]
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-RFC 6733 Diameter Base Protocol October 2012
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: accounting request corresponding to the authorization response, the
../data/rfc/rfc6733.txt- local realm implicitly indicates its agreement to provide the service
../data/rfc/rfc6733.txt- indicated in the authorization response. If the service cannot be
../data/rfc/rfc6733.txt- provided by the local realm, then a DIAMETER_UNABLE_TO_COMPLY error
../data/rfc/rfc6733.txt: message MUST be sent within the accounting request; a Diameter client
../data/rfc/rfc6733.txt- receiving an authorization response for a service that it cannot
../data/rfc/rfc6733.txt- perform MUST NOT substitute an alternate service and then send
../data/rfc/rfc6733.txt: accounting requests for the alternate service instead.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-3. Diameter Header
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- A summary of the Diameter header format is shown below. The fields
../data/rfc/rfc6733.txt- are transmitted in network byte order.
--
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Application-ID
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Application-ID is four octets and is used to identify for which
../data/rfc/rfc6733.txt- application the message is applicable. The application can be an
../data/rfc/rfc6733.txt: authentication application, an accounting application, or a
../data/rfc/rfc6733.txt- vendor-specific application.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- The value of the Application-ID field in the header MUST be the
../data/rfc/rfc6733.txt- same as any relevant Application-Id AVPs contained in the message.
../data/rfc/rfc6733.txt-
--
../data/rfc/rfc6733.txt- Section
../data/rfc/rfc6733.txt- Command Name Abbrev. Code Reference
../data/rfc/rfc6733.txt- --------------------------------------------------------
../data/rfc/rfc6733.txt- Abort-Session-Request ASR 274 8.5.1
../data/rfc/rfc6733.txt- Abort-Session-Answer ASA 274 8.5.2
../data/rfc/rfc6733.txt: Accounting-Request ACR 271 9.7.1
../data/rfc/rfc6733.txt: Accounting-Answer ACA 271 9.7.2
../data/rfc/rfc6733.txt- Capabilities-Exchange- CER 257 5.3.1
../data/rfc/rfc6733.txt- Request
../data/rfc/rfc6733.txt- Capabilities-Exchange- CEA 257 5.3.2
../data/rfc/rfc6733.txt- Answer
../data/rfc/rfc6733.txt- Device-Watchdog-Request DWR 280 5.5.1
--
../data/rfc/rfc6733.txt- Additional information, encoded within AVPs, may also be included in
../data/rfc/rfc6733.txt- answer messages.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-4. Diameter AVPs
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: Diameter AVPs carry specific authentication, accounting,
../data/rfc/rfc6733.txt- authorization, and routing information as well as configuration
../data/rfc/rfc6733.txt- details for the request and reply.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
--
../data/rfc/rfc6733.txt- AVP Section | |MUST |
../data/rfc/rfc6733.txt- Attribute Name Code Defined Data Type |MUST| NOT |
../data/rfc/rfc6733.txt- -----------------------------------------|----+-----|
../data/rfc/rfc6733.txt- Acct- 85 9.8.2 Unsigned32 | M | V |
../data/rfc/rfc6733.txt- Interim-Interval | | |
../data/rfc/rfc6733.txt: Accounting- 483 9.8.7 Enumerated | M | V |
../data/rfc/rfc6733.txt- Realtime-Required | | |
../data/rfc/rfc6733.txt- Acct- 50 9.8.5 UTF8String | M | V |
../data/rfc/rfc6733.txt- Multi-Session-Id | | |
../data/rfc/rfc6733.txt: Accounting- 485 9.8.3 Unsigned32 | M | V |
../data/rfc/rfc6733.txt- Record-Number | | |
../data/rfc/rfc6733.txt: Accounting- 480 9.8.1 Enumerated | M | V |
../data/rfc/rfc6733.txt- Record-Type | | |
../data/rfc/rfc6733.txt- Acct- 44 9.8.4 OctetString| M | V |
../data/rfc/rfc6733.txt- Session-Id | | |
../data/rfc/rfc6733.txt: Accounting- 287 9.8.6 Unsigned64 | M | V |
../data/rfc/rfc6733.txt- Sub-Session-Id | | |
../data/rfc/rfc6733.txt- Acct- 259 6.9 Unsigned32 | M | V |
../data/rfc/rfc6733.txt- Application-Id | | |
../data/rfc/rfc6733.txt- Auth- 258 6.8 Unsigned32 | M | V |
../data/rfc/rfc6733.txt- Application-Id | | |
--
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-6.9. Acct-Application-Id AVP
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- The Acct-Application-Id AVP (AVP Code 259) is of type Unsigned32 and
../data/rfc/rfc6733.txt: is used in order to advertise support of the accounting portion of an
../data/rfc/rfc6733.txt- application (see Section 2.4). If present in a message other than
../data/rfc/rfc6733.txt- CER and CEA, the value of the Acct-Application-Id AVP MUST match the
../data/rfc/rfc6733.txt- Application Id present in the Diameter message header.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-6.10. Inband-Security-Id AVP
--
../data/rfc/rfc6733.txt- an invalid password used by the user. Further attempts MUST only
../data/rfc/rfc6733.txt- be tried after prompting the user for a new password.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- DIAMETER_OUT_OF_SPACE 4002
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: A Diameter node received the accounting request but was unable to
../data/rfc/rfc6733.txt- commit it to stable storage due to a temporary lack of space.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- ELECTION_LOST 4003
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- The peer has determined that it has lost the election process and
--
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-8. Diameter User Sessions
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- In general, Diameter can provide two different types of services to
../data/rfc/rfc6733.txt- applications. The first involves authentication and authorization,
../data/rfc/rfc6733.txt: and it can optionally make use of accounting. The second only makes
../data/rfc/rfc6733.txt: use of accounting.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- When a service makes use of the authentication and/or authorization
../data/rfc/rfc6733.txt- portion of an application, and a user requests access to the network,
../data/rfc/rfc6733.txt- the Diameter client issues an auth request to its local server. The
../data/rfc/rfc6733.txt- auth request is defined in a service-specific Diameter application
../data/rfc/rfc6733.txt- (e.g., NASREQ). The request contains a Session-Id AVP, which is used
../data/rfc/rfc6733.txt: in subsequent messages (e.g., subsequent authorization, accounting,
../data/rfc/rfc6733.txt- etc.) relating to the user's session. The Session-Id AVP is a means
../data/rfc/rfc6733.txt- for the client and servers to correlate a Diameter message with a
../data/rfc/rfc6733.txt- user session.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- When a Diameter server authorizes a user to implement network
--
../data/rfc/rfc6733.txt- defined in a Diameter application document. However, the base
../data/rfc/rfc6733.txt- protocol does define a set of messages that are used to terminate
../data/rfc/rfc6733.txt- user sessions. These are used to allow servers that maintain state
../data/rfc/rfc6733.txt- information to free resources.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: When a service only makes use of the accounting portion of the
../data/rfc/rfc6733.txt- Diameter protocol, even in combination with an application, the
../data/rfc/rfc6733.txt- Session-Id is still used to identify user sessions. However, the
../data/rfc/rfc6733.txt- session termination messages are not used, since a session is
../data/rfc/rfc6733.txt: signaled as being terminated by issuing an accounting stop message.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Diameter may also be used for services that cannot be easily
../data/rfc/rfc6733.txt: categorized as authentication, authorization, or accounting (e.g.,
../data/rfc/rfc6733.txt- certain Third Generation Partnership Project Internet Multimedia
../data/rfc/rfc6733.txt- System (3GPP IMS) interfaces). In such cases, the finite state
../data/rfc/rfc6733.txt- machine defined in subsequent sections may not be applicable.
../data/rfc/rfc6733.txt- Therefore, the application itself MAY need to define its own finite
../data/rfc/rfc6733.txt- state machine. However, such application-specific state machines
--
../data/rfc/rfc6733.txt- Idle Service-specific authorization Send Idle
../data/rfc/rfc6733.txt- request received, and service-
../data/rfc/rfc6733.txt- successfully processed specific
../data/rfc/rfc6733.txt- answer
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt:8.2. Accounting Session State Machine
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- The following state machines MUST be supported for applications that
../data/rfc/rfc6733.txt: have an accounting portion or that require only accounting services.
../data/rfc/rfc6733.txt- The first state machine is to be observed by clients.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: See Section 9.7 for Accounting Command Codes and Section 9.8 for
../data/rfc/rfc6733.txt: Accounting AVPs.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: The server side in the accounting state machine depends in some cases
../data/rfc/rfc6733.txt- on the particular application. The Diameter base protocol defines a
../data/rfc/rfc6733.txt- default state machine that MUST be followed by all applications that
../data/rfc/rfc6733.txt- have not specified other state machines. This is the second state
../data/rfc/rfc6733.txt- machine in this section described below.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- The default server side state machine requires the reception of
../data/rfc/rfc6733.txt: accounting records in any order and at any time, and it does not
../data/rfc/rfc6733.txt- place any standards requirement on the processing of these records.
../data/rfc/rfc6733.txt- Implementations of Diameter may perform checking, ordering,
../data/rfc/rfc6733.txt- correlation, fraud detection, and other tasks based on these records.
../data/rfc/rfc6733.txt- AVPs may need to be inspected as a part of these tasks. The tasks
../data/rfc/rfc6733.txt- can happen either immediately after record reception or in a post-
../data/rfc/rfc6733.txt- processing phase. However, as these tasks are typically application
../data/rfc/rfc6733.txt- or even policy dependent, they are not standardized by the Diameter
../data/rfc/rfc6733.txt- specifications. Applications MAY define requirements on when to
../data/rfc/rfc6733.txt: accept accounting records based on the used value of Accounting-
../data/rfc/rfc6733.txt- Realtime-Required AVP, credit-limit checks, and so on.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- However, the Diameter base protocol defines one optional server side
../data/rfc/rfc6733.txt- state machine that MAY be followed by applications that require
../data/rfc/rfc6733.txt: keeping track of the session state at the accounting server. Note
../data/rfc/rfc6733.txt- that such tracking is incompatible with the ability to sustain long
../data/rfc/rfc6733.txt- duration connectivity problems. Therefore, the use of this state
../data/rfc/rfc6733.txt- machine is recommended only in applications where the value of the
../data/rfc/rfc6733.txt: Accounting-Realtime-Required AVP is DELIVER_AND_GRANT; hence,
../data/rfc/rfc6733.txt: accounting connectivity problems are required to cause the serviced
../data/rfc/rfc6733.txt- user to be disconnected. Otherwise, records produced by the client
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-Fajardo, et al. Standards Track [Page 104]
--
../data/rfc/rfc6733.txt- may be lost by the server, which no longer accepts them after the
../data/rfc/rfc6733.txt- connectivity is re-established. This state machine is the third
../data/rfc/rfc6733.txt- state machine in this section. The state machine is supervised by a
../data/rfc/rfc6733.txt- supervision session timer Ts, whose value should be reasonably higher
../data/rfc/rfc6733.txt- than the Acct_Interim_Interval value. Ts MAY be set to two times the
../data/rfc/rfc6733.txt: value of the Acct_Interim_Interval so as to avoid the accounting
../data/rfc/rfc6733.txt- session in the Diameter server to change to Idle state in case of
../data/rfc/rfc6733.txt- short transient network failure.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Any event not listed in the state machines MUST be considered as an
../data/rfc/rfc6733.txt- error condition, and a corresponding answer, if applicable, MUST be
--
../data/rfc/rfc6733.txt- In the state table, the event "Failure to send" means that the
../data/rfc/rfc6733.txt- Diameter client is unable to communicate with the desired
../data/rfc/rfc6733.txt- destination. This could be due to the peer being down, or due to the
../data/rfc/rfc6733.txt- peer sending back a transient failure or temporary protocol error
../data/rfc/rfc6733.txt- notification DIAMETER_OUT_OF_SPACE, DIAMETER_TOO_BUSY, or
../data/rfc/rfc6733.txt: DIAMETER_LOOP_DETECTED in the Result-Code AVP of the Accounting
../data/rfc/rfc6733.txt- Answer command.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- The event "Failed answer" means that the Diameter client received a
../data/rfc/rfc6733.txt: non-transient failure notification in the Accounting Answer command.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Note that the action "Disconnect user/dev" MUST also have an effect
../data/rfc/rfc6733.txt- on the authorization session state table, e.g., cause the STR message
../data/rfc/rfc6733.txt- to be sent, if the given application has both authentication/
../data/rfc/rfc6733.txt: authorization and accounting portions.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- The states PendingS, PendingI, PendingL, PendingE, and PendingB stand
../data/rfc/rfc6733.txt: for pending states to wait for an answer to an accounting request
../data/rfc/rfc6733.txt- related to a Start, Interim, Stop, Event, or buffered record,
../data/rfc/rfc6733.txt- respectively.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: CLIENT, ACCOUNTING
../data/rfc/rfc6733.txt- State Event Action New State
../data/rfc/rfc6733.txt- ---------------------------------------------------------------
../data/rfc/rfc6733.txt- Idle Client or device requests Send PendingS
../data/rfc/rfc6733.txt: access accounting
../data/rfc/rfc6733.txt- start req.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Idle Client or device requests Send PendingE
../data/rfc/rfc6733.txt: a one-time service accounting
../data/rfc/rfc6733.txt- event req
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Idle Records in storage Send PendingB
../data/rfc/rfc6733.txt- record
../data/rfc/rfc6733.txt-
--
../data/rfc/rfc6733.txt-Fajardo, et al. Standards Track [Page 105]
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-RFC 6733 Diameter Base Protocol October 2012
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: PendingS Successful accounting Open
../data/rfc/rfc6733.txt- start answer received
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- PendingS Failure to send and buffer Store Open
../data/rfc/rfc6733.txt- space available and real time Start
../data/rfc/rfc6733.txt- not equal to DELIVER_AND_GRANT Record
--
../data/rfc/rfc6733.txt- PendingS Failure to send and no Disconnect Idle
../data/rfc/rfc6733.txt- buffer space available and user/dev
../data/rfc/rfc6733.txt- real time not equal to
../data/rfc/rfc6733.txt- GRANT_AND_LOSE
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: PendingS Failed accounting start answer Open
../data/rfc/rfc6733.txt- received and real time equal
../data/rfc/rfc6733.txt- to GRANT_AND_LOSE
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: PendingS Failed accounting start answer Disconnect Idle
../data/rfc/rfc6733.txt- received and real time not user/dev
../data/rfc/rfc6733.txt- equal to GRANT_AND_LOSE
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- PendingS User service terminated Store PendingS
../data/rfc/rfc6733.txt- stop
../data/rfc/rfc6733.txt- record
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Open Interim interval elapses Send PendingI
../data/rfc/rfc6733.txt: accounting
../data/rfc/rfc6733.txt- interim
../data/rfc/rfc6733.txt- record
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Open User service terminated Send PendingL
../data/rfc/rfc6733.txt: accounting
../data/rfc/rfc6733.txt- stop req.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: PendingI Successful accounting interim Open
../data/rfc/rfc6733.txt- answer received
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- PendingI Failure to send and (buffer Store Open
../data/rfc/rfc6733.txt- space available or old interim
../data/rfc/rfc6733.txt- record can be overwritten) record
--
../data/rfc/rfc6733.txt- PendingI Failure to send and no Disconnect Idle
../data/rfc/rfc6733.txt- buffer space available and user/dev
../data/rfc/rfc6733.txt- real time not equal to
../data/rfc/rfc6733.txt- GRANT_AND_LOSE
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: PendingI Failed accounting interim Open
../data/rfc/rfc6733.txt- answer received and real time
../data/rfc/rfc6733.txt- equal to GRANT_AND_LOSE
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: PendingI Failed accounting interim Disconnect Idle
../data/rfc/rfc6733.txt- answer received and user/dev
../data/rfc/rfc6733.txt- real time not equal to
../data/rfc/rfc6733.txt- GRANT_AND_LOSE
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- PendingI User service terminated Store PendingI
../data/rfc/rfc6733.txt- stop
../data/rfc/rfc6733.txt- record
../data/rfc/rfc6733.txt: PendingE Successful accounting Idle
../data/rfc/rfc6733.txt- event answer received
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- PendingE Failure to send and buffer Store Idle
../data/rfc/rfc6733.txt- space available event
../data/rfc/rfc6733.txt- record
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- PendingE Failure to send and no buffer Idle
../data/rfc/rfc6733.txt- space available
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: PendingE Failed accounting event answer Idle
../data/rfc/rfc6733.txt- received
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: PendingB Successful accounting answer Delete Idle
../data/rfc/rfc6733.txt- received record
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- PendingB Failure to send Idle
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: PendingB Failed accounting answer Delete Idle
../data/rfc/rfc6733.txt- received record
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: PendingL Successful accounting Idle
../data/rfc/rfc6733.txt- stop answer received
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- PendingL Failure to send and buffer Store Idle
../data/rfc/rfc6733.txt- space available stop
../data/rfc/rfc6733.txt- record
--
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- PendingL Failure to send and no buffer Idle
../data/rfc/rfc6733.txt- space available
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: PendingL Failed accounting stop answer Idle
../data/rfc/rfc6733.txt- received
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: SERVER, STATELESS ACCOUNTING
../data/rfc/rfc6733.txt- State Event Action New State
../data/rfc/rfc6733.txt- ---------------------------------------------------------------
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: Idle Accounting start request Send Idle
../data/rfc/rfc6733.txt: received and successfully accounting
../data/rfc/rfc6733.txt- processed. start
../data/rfc/rfc6733.txt- answer
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: Idle Accounting event request Send Idle
../data/rfc/rfc6733.txt: received and successfully accounting
../data/rfc/rfc6733.txt- processed. event
../data/rfc/rfc6733.txt- answer
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Idle Interim record received Send Idle
../data/rfc/rfc6733.txt: and successfully processed. accounting
../data/rfc/rfc6733.txt- interim
../data/rfc/rfc6733.txt- answer
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: Idle Accounting stop request Send Idle
../data/rfc/rfc6733.txt: received and successfully accounting
../data/rfc/rfc6733.txt- processed stop answer
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: Idle Accounting request received; Send Idle
../data/rfc/rfc6733.txt: no space left to store accounting
../data/rfc/rfc6733.txt- records answer;
../data/rfc/rfc6733.txt- Result-Code =
../data/rfc/rfc6733.txt- OUT_OF_
../data/rfc/rfc6733.txt- SPACE
../data/rfc/rfc6733.txt-
--
../data/rfc/rfc6733.txt-Fajardo, et al. Standards Track [Page 108]
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-RFC 6733 Diameter Base Protocol October 2012
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: SERVER, STATEFUL ACCOUNTING
../data/rfc/rfc6733.txt- State Event Action New State
../data/rfc/rfc6733.txt- ---------------------------------------------------------------
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: Idle Accounting start request Send Open
../data/rfc/rfc6733.txt: received and successfully accounting
../data/rfc/rfc6733.txt- processed. start
../data/rfc/rfc6733.txt- answer;
../data/rfc/rfc6733.txt- Start Ts
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: Idle Accounting event request Send Idle
../data/rfc/rfc6733.txt: received and successfully accounting
../data/rfc/rfc6733.txt- processed. event
../data/rfc/rfc6733.txt- answer
../data/rfc/rfc6733.txt: Idle Accounting request received; Send Idle
../data/rfc/rfc6733.txt: no space left to store accounting
../data/rfc/rfc6733.txt- records answer;
../data/rfc/rfc6733.txt- Result-Code =
../data/rfc/rfc6733.txt- OUT_OF_
../data/rfc/rfc6733.txt- SPACE
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Open Interim record received Send Open
../data/rfc/rfc6733.txt: and successfully processed. accounting
../data/rfc/rfc6733.txt- interim
../data/rfc/rfc6733.txt- answer;
../data/rfc/rfc6733.txt- Restart Ts
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: Open Accounting stop request Send Idle
../data/rfc/rfc6733.txt: received and successfully accounting
../data/rfc/rfc6733.txt- processed stop answer;
../data/rfc/rfc6733.txt- Stop Ts
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: Open Accounting request received; Send Idle
../data/rfc/rfc6733.txt: no space left to store accounting
../data/rfc/rfc6733.txt- records answer;
../data/rfc/rfc6733.txt- Result-Code =
../data/rfc/rfc6733.txt- OUT_OF_
../data/rfc/rfc6733.txt- SPACE;
../data/rfc/rfc6733.txt- Stop Ts
--
../data/rfc/rfc6733.txt- following the Diameter header (see Section 3).
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- The Session-Id MUST be globally and eternally unique, as it is meant
../data/rfc/rfc6733.txt- to uniquely identify a user session without reference to any other
../data/rfc/rfc6733.txt- information, and it may be needed to correlate historical
../data/rfc/rfc6733.txt: authentication information with accounting information. The
../data/rfc/rfc6733.txt- Session-Id includes a mandatory portion and an implementation-defined
../data/rfc/rfc6733.txt- portion; a recommended format for the implementation-defined portion
../data/rfc/rfc6733.txt- is outlined below.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- The Session-Id MUST begin with the sender's identity encoded in the
--
../data/rfc/rfc6733.txt- accesspoint7.example.com;1876543210;523;mobile@200.1.1.88
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- The Session-Id is created by the Diameter application initiating the
../data/rfc/rfc6733.txt- session, which, in most cases, is done by the client. Note that a
../data/rfc/rfc6733.txt- Session-Id MAY be used for both the authentication, authorization,
../data/rfc/rfc6733.txt: and accounting commands of a given application.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-8.9. Authorization-Lifetime AVP
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- The Authorization-Lifetime AVP (AVP Code 291) is of type Unsigned32
../data/rfc/rfc6733.txt- and contains the maximum number of seconds of service to be provided
--
../data/rfc/rfc6733.txt- When set, the STR message for this session MUST NOT include the
../data/rfc/rfc6733.txt- Destination-Host AVP. When cleared, the default value, the
../data/rfc/rfc6733.txt- Destination-Host AVP MUST be present in the STR message for this
../data/rfc/rfc6733.txt- session.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: ACCOUNTING 4
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: When set, all accounting messages for this session MUST NOT
../data/rfc/rfc6733.txt- include the Destination-Host AVP. When cleared, the default
../data/rfc/rfc6733.txt- value, the Destination-Host AVP, if known, MUST be present in all
../data/rfc/rfc6733.txt: accounting messages for this session.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-8.18. Session-Server-Failover AVP
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- The Session-Server-Failover AVP (AVP Code 271) is of type Enumerated
../data/rfc/rfc6733.txt- and MAY be present in application-specific authorization answer
--
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- The Class AVP (AVP Code 25) is of type OctetString and is used by
../data/rfc/rfc6733.txt- Diameter servers to return state information to the access device.
../data/rfc/rfc6733.txt- When one or more Class AVPs are present in application-specific
../data/rfc/rfc6733.txt- authorization answer messages, they MUST be present in subsequent re-
../data/rfc/rfc6733.txt: authorization, session termination and accounting messages. Class
../data/rfc/rfc6733.txt- AVPs found in a re-authorization answer message override the ones
../data/rfc/rfc6733.txt- found in any previous authorization answer message. Diameter server
../data/rfc/rfc6733.txt- implementations SHOULD NOT return Class AVPs that require more than
../data/rfc/rfc6733.txt- 4096 bytes of storage on the Diameter client. A Diameter client that
../data/rfc/rfc6733.txt- receives Class AVPs whose size exceeds local available storage MUST
../data/rfc/rfc6733.txt- terminate the session.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-8.21. Event-Timestamp AVP
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- The Event-Timestamp (AVP Code 55) is of type Time and MAY be included
../data/rfc/rfc6733.txt: in an Accounting-Request and Accounting-Answer messages to record the
../data/rfc/rfc6733.txt- time that the reported event occurred, in seconds since January 1,
../data/rfc/rfc6733.txt- 1900 00:00 UTC.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
--
../data/rfc/rfc6733.txt-Fajardo, et al. Standards Track [Page 122]
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-RFC 6733 Diameter Base Protocol October 2012
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt:9. Accounting
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: This accounting protocol is based on a server directed model with
../data/rfc/rfc6733.txt: capabilities for real-time delivery of accounting information.
../data/rfc/rfc6733.txt- Several fault resilience methods [RFC2975] have been built into the
../data/rfc/rfc6733.txt: protocol in order minimize loss of accounting data in various fault
../data/rfc/rfc6733.txt- situations and under different assumptions about the capabilities of
../data/rfc/rfc6733.txt- the used devices.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-9.1. Server Directed Model
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- The server directed model means that the device generating the
../data/rfc/rfc6733.txt: accounting data gets information from either the authorization server
../data/rfc/rfc6733.txt: (if contacted) or the accounting server regarding the way accounting
../data/rfc/rfc6733.txt: data shall be forwarded. This information includes accounting record
../data/rfc/rfc6733.txt- timeliness requirements.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: As discussed in [RFC2975], real-time transfer of accounting records
../data/rfc/rfc6733.txt- is a requirement, such as the need to perform credit-limit checks and
../data/rfc/rfc6733.txt: fraud detection. Note that batch accounting is not a requirement,
../data/rfc/rfc6733.txt- and is therefore not supported by Diameter. Should batched
../data/rfc/rfc6733.txt: accounting be required in the future, a new Diameter application will
../data/rfc/rfc6733.txt- need to be created, or it could be handled using another protocol.
../data/rfc/rfc6733.txt: Note, however, that even if at the Diameter layer, accounting
../data/rfc/rfc6733.txt- requests are processed one by one; transport protocols used under
../data/rfc/rfc6733.txt- Diameter typically batch several requests in the same packet under
../data/rfc/rfc6733.txt- heavy traffic conditions. This may be sufficient for many
../data/rfc/rfc6733.txt- applications.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- The authorization server (chain) directs the selection of proper
../data/rfc/rfc6733.txt- transfer strategy, based on its knowledge of the user and
../data/rfc/rfc6733.txt- relationships of roaming partnerships. The server (or agents) uses
../data/rfc/rfc6733.txt: the Acct-Interim-Interval and Accounting-Realtime-Required AVPs to
../data/rfc/rfc6733.txt- control the operation of the Diameter peer operating as a client.
../data/rfc/rfc6733.txt- The Acct-Interim-Interval AVP, when present, instructs the Diameter
../data/rfc/rfc6733.txt: node acting as a client to produce accounting records continuously
../data/rfc/rfc6733.txt: even during a session. Accounting-Realtime-Required AVP is used to
../data/rfc/rfc6733.txt: control the behavior of the client when the transfer of accounting
../data/rfc/rfc6733.txt- records from the Diameter client is delayed or unsuccessful.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: The Diameter accounting server MAY override the interim interval or
../data/rfc/rfc6733.txt- the real-time requirements by including the Acct-Interim-Interval or
../data/rfc/rfc6733.txt: Accounting-Realtime-Required AVP in the Accounting-Answer message.
../data/rfc/rfc6733.txt- When one of these AVPs is present, the latest value received SHOULD
../data/rfc/rfc6733.txt: be used in further accounting activities for the same session.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
--
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-9.2. Protocol Messages
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- A Diameter node that receives a successful authentication and/or
../data/rfc/rfc6733.txt- authorization message from the Diameter server SHOULD collect
../data/rfc/rfc6733.txt: accounting information for the session. The Accounting-Request
../data/rfc/rfc6733.txt: message is used to transmit the accounting information to the
../data/rfc/rfc6733.txt: Diameter server, which MUST reply with the Accounting-Answer message
../data/rfc/rfc6733.txt: to confirm reception. The Accounting-Answer message includes the
../data/rfc/rfc6733.txt- Result-Code AVP, which MAY indicate that an error was present in the
../data/rfc/rfc6733.txt: accounting message. The value of the Accounting-Realtime-Required
../data/rfc/rfc6733.txt- AVP received earlier for the session in question may indicate that
../data/rfc/rfc6733.txt: the user's session has to be terminated when a rejected Accounting-
../data/rfc/rfc6733.txt- Request message was received.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt:9.3. Accounting Application Extension and Requirements
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Each Diameter application (e.g., NASREQ, Mobile IP) SHOULD define its
../data/rfc/rfc6733.txt: service-specific AVPs that MUST be present in the Accounting-Request
../data/rfc/rfc6733.txt: message in a section titled "Accounting AVPs". The application MUST
../data/rfc/rfc6733.txt- assume that the AVPs described in this document will be present in
../data/rfc/rfc6733.txt: all Accounting messages, so only their respective service-specific
../data/rfc/rfc6733.txt- AVPs need to be defined in that section.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Applications have the option of using one or both of the following
../data/rfc/rfc6733.txt: accounting application extension models:
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: Split Accounting Service
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: The accounting message will carry the Application Id of the
../data/rfc/rfc6733.txt: Diameter base accounting application (see Section 2.4).
../data/rfc/rfc6733.txt: Accounting messages may be routed to Diameter nodes other than the
../data/rfc/rfc6733.txt- corresponding Diameter application. These nodes might be
../data/rfc/rfc6733.txt: centralized accounting servers that provide accounting service for
../data/rfc/rfc6733.txt- multiple different Diameter applications. These nodes MUST
../data/rfc/rfc6733.txt: advertise the Diameter base accounting Application Id during
../data/rfc/rfc6733.txt- capabilities exchange.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: Coupled Accounting Service
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: The accounting message will carry the Application Id of the
../data/rfc/rfc6733.txt- application that is using it. The application itself will process
../data/rfc/rfc6733.txt: the received accounting records or forward them to an accounting
../data/rfc/rfc6733.txt: server. There is no accounting application advertisement required
../data/rfc/rfc6733.txt: during capabilities exchange, and the accounting messages will be
../data/rfc/rfc6733.txt- routed the same way as any of the other application messages.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: In cases where an application does not define its own accounting
../data/rfc/rfc6733.txt: service, it is preferred that the split accounting model be used.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-Fajardo, et al. Standards Track [Page 124]
../data/rfc/rfc6733.txt-
--
../data/rfc/rfc6733.txt- loss and network faults of a temporary nature.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Diameter peers acting as clients MUST implement the use of failover
../data/rfc/rfc6733.txt- to guard against server failures and certain network failures.
../data/rfc/rfc6733.txt- Diameter peers acting as agents or related off-line processing
../data/rfc/rfc6733.txt: systems MUST detect duplicate accounting records caused by the
../data/rfc/rfc6733.txt- sending of the same record to several servers and duplication of
../data/rfc/rfc6733.txt- messages in transit. This detection MUST be based on the inspection
../data/rfc/rfc6733.txt: of the Session-Id and Accounting-Record-Number AVP pairs. Appendix C
../data/rfc/rfc6733.txt- discusses duplicate detection needs and implementation issues.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Diameter clients MAY have non-volatile memory for the safe storage of
../data/rfc/rfc6733.txt: accounting records over reboots or extended network failures, network
../data/rfc/rfc6733.txt- partitions, and server failures. If such memory is available, the
../data/rfc/rfc6733.txt: client SHOULD store new accounting records there as soon as the
../data/rfc/rfc6733.txt- records are created and until a positive acknowledgement of their
../data/rfc/rfc6733.txt- reception from the Diameter server has been received. Upon a reboot,
../data/rfc/rfc6733.txt- the client MUST start sending the records in the non-volatile memory
../data/rfc/rfc6733.txt: to the accounting server with the appropriate modifications in
../data/rfc/rfc6733.txt- termination cause, session length, and other relevant information in
../data/rfc/rfc6733.txt- the records.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- A further application of this protocol may include AVPs to control
../data/rfc/rfc6733.txt: the maximum number of accounting records that may be stored in the
../data/rfc/rfc6733.txt- Diameter client without committing them to the non-volatile memory or
../data/rfc/rfc6733.txt- transferring them to the Diameter server.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: The client SHOULD NOT remove the accounting data from any of its
../data/rfc/rfc6733.txt: memory areas before the correct Accounting-Answer has been received.
../data/rfc/rfc6733.txt- The client MAY remove the oldest, undelivered, or as yet
../data/rfc/rfc6733.txt: unacknowledged accounting data if it runs out of resources such as
../data/rfc/rfc6733.txt- memory. It is an implementation-dependent matter for the client to
../data/rfc/rfc6733.txt- accept new sessions under this condition.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt:9.5. Accounting Records
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: In all accounting records, the Session-Id AVP MUST be present; the
../data/rfc/rfc6733.txt- User-Name AVP MUST be present if it is available to the Diameter
../data/rfc/rfc6733.txt- client.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: Different types of accounting records are sent depending on the
../data/rfc/rfc6733.txt- actual type of accounted service and the authorization server's
../data/rfc/rfc6733.txt: directions for interim accounting. If the accounted service is a
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
--
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-RFC 6733 Diameter Base Protocol October 2012
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- one-time event, meaning that the start and stop of the event are
../data/rfc/rfc6733.txt: simultaneous, then the Accounting-Record-Type AVP MUST be present and
../data/rfc/rfc6733.txt- set to the value EVENT_RECORD.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- If the accounted service is of a measurable length, then the AVP MUST
../data/rfc/rfc6733.txt- use the values START_RECORD, STOP_RECORD, and possibly,
../data/rfc/rfc6733.txt- INTERIM_RECORD. If the authorization server has not directed interim
../data/rfc/rfc6733.txt: accounting to be enabled for the session, two accounting records MUST
../data/rfc/rfc6733.txt- be generated for each service of type session. When the initial
../data/rfc/rfc6733.txt: Accounting-Request for a given session is sent, the Accounting-
../data/rfc/rfc6733.txt- Record-Type AVP MUST be set to the value START_RECORD. When the last
../data/rfc/rfc6733.txt: Accounting-Request is sent, the value MUST be STOP_RECORD.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: If the authorization server has directed interim accounting to be
../data/rfc/rfc6733.txt- enabled, the Diameter client MUST produce additional records between
../data/rfc/rfc6733.txt- the START_RECORD and STOP_RECORD, marked INTERIM_RECORD. The
../data/rfc/rfc6733.txt- production of these records is directed by Acct-Interim-Interval as
../data/rfc/rfc6733.txt- well as any re-authentication or re-authorization of the session.
../data/rfc/rfc6733.txt: The Diameter client MUST overwrite any previous interim accounting
../data/rfc/rfc6733.txt- records that are locally stored for delivery, if a new record is
../data/rfc/rfc6733.txt- being generated for the same session. This ensures that only one
../data/rfc/rfc6733.txt- pending interim record can exist on an access device for any given
../data/rfc/rfc6733.txt- session.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: A particular value of Accounting-Sub-Session-Id MUST appear only in
../data/rfc/rfc6733.txt: one sequence of accounting records from a Diameter client, except for
../data/rfc/rfc6733.txt- the purposes of retransmission. The one sequence that is sent MUST
../data/rfc/rfc6733.txt: be either one record with Accounting-Record-Type AVP set to the value
../data/rfc/rfc6733.txt- EVENT_RECORD or several records starting with one having the value
../data/rfc/rfc6733.txt- START_RECORD, followed by zero or more INTERIM_RECORDs and a single
../data/rfc/rfc6733.txt- STOP_RECORD. A particular Diameter application specification MUST
../data/rfc/rfc6733.txt- define the type of sequences that MUST be used.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt:9.6. Correlation of Accounting Records
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: If an application uses accounting messages, it can correlate
../data/rfc/rfc6733.txt: accounting records with a specific application session by using the
../data/rfc/rfc6733.txt: Session-Id of the particular application session in the accounting
../data/rfc/rfc6733.txt: messages. Accounting messages MAY also use a different Session-Id
../data/rfc/rfc6733.txt- from that of the application sessions, in which case, other session-
../data/rfc/rfc6733.txt- related information is needed to perform correlation.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: In cases where an application requires multiple accounting sub-
../data/rfc/rfc6733.txt: sessions, an Accounting-Sub-Session-Id AVP is used to differentiate
../data/rfc/rfc6733.txt- each sub-session. The Session-Id would remain constant for all sub-
../data/rfc/rfc6733.txt- sessions and is used to correlate all the sub-sessions to a
../data/rfc/rfc6733.txt- particular application session. Note that receiving a STOP_RECORD
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
--
../data/rfc/rfc6733.txt-Fajardo, et al. Standards Track [Page 126]
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-RFC 6733 Diameter Base Protocol October 2012
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: with no Accounting-Sub-Session-Id AVP when sub-sessions were
../data/rfc/rfc6733.txt- originally used in the START_RECORD messages implies that all sub-
../data/rfc/rfc6733.txt- sessions are terminated.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- There are also cases where an application needs to correlate multiple
../data/rfc/rfc6733.txt: application sessions into a single accounting record; the accounting
../data/rfc/rfc6733.txt- record may span multiple different Diameter applications and sessions
../data/rfc/rfc6733.txt- used by the same user at a given time. In such cases, the Acct-
../data/rfc/rfc6733.txt- Multi-Session-Id AVP is used. The Acct-Multi-Session-Id AVP SHOULD
../data/rfc/rfc6733.txt- be signaled by the server to the access device (typically, during
../data/rfc/rfc6733.txt- authorization) when it determines that a request belongs to an
../data/rfc/rfc6733.txt- existing session. The access device MUST then include the Acct-
../data/rfc/rfc6733.txt: Multi-Session-Id AVP in all subsequent accounting messages.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- The Acct-Multi-Session-Id AVP MAY include the value of the original
../data/rfc/rfc6733.txt- Session-Id. Its contents are implementation specific, but the MUST
../data/rfc/rfc6733.txt- be globally unique across other Acct-Multi-Session-Ids and MUST NOT
../data/rfc/rfc6733.txt- change during the life of a session.
--
../data/rfc/rfc6733.txt- session that is being accounted, and it MAY define the concept of a
../data/rfc/rfc6733.txt- multi-session. For instance, the NASREQ DIAMETER application treats
../data/rfc/rfc6733.txt- a single PPP connection to a Network Access Server as one session and
../data/rfc/rfc6733.txt- a set of Multilink PPP sessions as one multi-session.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt:9.7. Accounting Command Codes
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- This section defines Command Code values that MUST be supported by
../data/rfc/rfc6733.txt: all Diameter implementations that provide accounting services.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt:9.7.1. Accounting-Request
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: The Accounting-Request (ACR) command, indicated by the Command Code
../data/rfc/rfc6733.txt- field set to 271 and the Command Flags' 'R' bit set, is sent by a
../data/rfc/rfc6733.txt: Diameter node, acting as a client, in order to exchange accounting
../data/rfc/rfc6733.txt- information with a peer.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: In addition to the AVPs listed below, Accounting-Request messages
../data/rfc/rfc6733.txt: SHOULD include service-specific accounting AVPs.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
--
../data/rfc/rfc6733.txt- <ACR> ::= < Diameter Header: 271, REQ, PXY >
../data/rfc/rfc6733.txt- < Session-Id >
../data/rfc/rfc6733.txt- { Origin-Host }
../data/rfc/rfc6733.txt- { Origin-Realm }
../data/rfc/rfc6733.txt- { Destination-Realm }
../data/rfc/rfc6733.txt: { Accounting-Record-Type }
../data/rfc/rfc6733.txt: { Accounting-Record-Number }
../data/rfc/rfc6733.txt- [ Acct-Application-Id ]
../data/rfc/rfc6733.txt- [ Vendor-Specific-Application-Id ]
../data/rfc/rfc6733.txt- [ User-Name ]
../data/rfc/rfc6733.txt- [ Destination-Host ]
../data/rfc/rfc6733.txt: [ Accounting-Sub-Session-Id ]
../data/rfc/rfc6733.txt- [ Acct-Session-Id ]
../data/rfc/rfc6733.txt- [ Acct-Multi-Session-Id ]
../data/rfc/rfc6733.txt- [ Acct-Interim-Interval ]
../data/rfc/rfc6733.txt: [ Accounting-Realtime-Required ]
../data/rfc/rfc6733.txt- [ Origin-State-Id ]
../data/rfc/rfc6733.txt- [ Event-Timestamp ]
../data/rfc/rfc6733.txt- * [ Proxy-Info ]
../data/rfc/rfc6733.txt- * [ Route-Record ]
../data/rfc/rfc6733.txt- * [ AVP ]
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt:9.7.2. Accounting-Answer
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: The Accounting-Answer (ACA) command, indicated by the Command Code
../data/rfc/rfc6733.txt- field set to 271 and the Command Flags' 'R' bit cleared, is used to
../data/rfc/rfc6733.txt: acknowledge an Accounting-Request command. The Accounting-Answer
../data/rfc/rfc6733.txt- command contains the same Session-Id as the corresponding request.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- Only the target Diameter server, known as the home Diameter server,
../data/rfc/rfc6733.txt: SHOULD respond with the Accounting-Answer command.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: In addition to the AVPs listed below, Accounting-Answer messages
../data/rfc/rfc6733.txt: SHOULD include service-specific accounting AVPs.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
--
../data/rfc/rfc6733.txt- <ACA> ::= < Diameter Header: 271, PXY >
../data/rfc/rfc6733.txt- < Session-Id >
../data/rfc/rfc6733.txt- { Result-Code }
../data/rfc/rfc6733.txt- { Origin-Host }
../data/rfc/rfc6733.txt- { Origin-Realm }
../data/rfc/rfc6733.txt: { Accounting-Record-Type }
../data/rfc/rfc6733.txt: { Accounting-Record-Number }
../data/rfc/rfc6733.txt- [ Acct-Application-Id ]
../data/rfc/rfc6733.txt- [ Vendor-Specific-Application-Id ]
../data/rfc/rfc6733.txt- [ User-Name ]
../data/rfc/rfc6733.txt: [ Accounting-Sub-Session-Id ]
../data/rfc/rfc6733.txt- [ Acct-Session-Id ]
../data/rfc/rfc6733.txt- [ Acct-Multi-Session-Id ]
../data/rfc/rfc6733.txt- [ Error-Message ]
../data/rfc/rfc6733.txt- [ Error-Reporting-Host ]
../data/rfc/rfc6733.txt- [ Failed-AVP ]
../data/rfc/rfc6733.txt- [ Acct-Interim-Interval ]
../data/rfc/rfc6733.txt: [ Accounting-Realtime-Required ]
../data/rfc/rfc6733.txt- [ Origin-State-Id ]
../data/rfc/rfc6733.txt- [ Event-Timestamp ]
../data/rfc/rfc6733.txt- * [ Proxy-Info ]
../data/rfc/rfc6733.txt- * [ AVP ]
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt:9.8. Accounting AVPs
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: This section contains AVPs that describe accounting usage information
../data/rfc/rfc6733.txt- related to a specific session.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt:9.8.1. Accounting-Record-Type AVP
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: The Accounting-Record-Type AVP (AVP Code 480) is of type Enumerated
../data/rfc/rfc6733.txt: and contains the type of accounting record being sent. The following
../data/rfc/rfc6733.txt: values are currently defined for the Accounting-Record-Type AVP:
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- EVENT_RECORD 1
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: An Accounting Event Record is used to indicate that a one-time
../data/rfc/rfc6733.txt- event has occurred (meaning that the start and end of the event
../data/rfc/rfc6733.txt- are simultaneous). This record contains all information relevant
../data/rfc/rfc6733.txt- to the service, and it is the only record of the service.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
--
../data/rfc/rfc6733.txt-RFC 6733 Diameter Base Protocol October 2012
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- START_RECORD 2
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: Accounting Start, Interim, and Stop Records are used to indicate
../data/rfc/rfc6733.txt- that a service of a measurable length has been given. An
../data/rfc/rfc6733.txt: Accounting Start Record is used to initiate an accounting session
../data/rfc/rfc6733.txt: and contains accounting information that is relevant to the
../data/rfc/rfc6733.txt- initiation of the session.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- INTERIM_RECORD 3
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: An Interim Accounting Record contains cumulative accounting
../data/rfc/rfc6733.txt: information for an existing accounting session. Interim
../data/rfc/rfc6733.txt: Accounting Records SHOULD be sent every time a re-authentication
../data/rfc/rfc6733.txt- or re-authorization occurs. Further, additional interim record
../data/rfc/rfc6733.txt- triggers MAY be defined by application-specific Diameter
../data/rfc/rfc6733.txt- applications. The selection of whether to use INTERIM_RECORD
../data/rfc/rfc6733.txt- records is done by the Acct-Interim-Interval AVP.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- STOP_RECORD 4
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: An Accounting Stop Record is sent to terminate an accounting
../data/rfc/rfc6733.txt: session and contains cumulative accounting information relevant to
../data/rfc/rfc6733.txt- the existing session.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-9.8.2. Acct-Interim-Interval AVP
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- The Acct-Interim-Interval AVP (AVP Code 85) is of type Unsigned32 and
../data/rfc/rfc6733.txt- is sent from the Diameter home authorization server to the Diameter
../data/rfc/rfc6733.txt- client. The client uses information in this AVP to decide how and
../data/rfc/rfc6733.txt: when to produce accounting records. With different values in this
../data/rfc/rfc6733.txt: AVP, service sessions can result in one, two, or two+N accounting
../data/rfc/rfc6733.txt- records, based on the needs of the home organization. The following
../data/rfc/rfc6733.txt: accounting record production behavior is directed by the inclusion of
../data/rfc/rfc6733.txt- this AVP:
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- 1. The omission of the Acct-Interim-Interval AVP or its inclusion
../data/rfc/rfc6733.txt- with Value field set to 0 means that EVENT_RECORD, START_RECORD,
../data/rfc/rfc6733.txt- and STOP_RECORD are produced, as appropriate for the service.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- 2. The inclusion of the AVP with Value field set to a non-zero value
../data/rfc/rfc6733.txt- means that INTERIM_RECORD records MUST be produced between the
../data/rfc/rfc6733.txt- START_RECORD and STOP_RECORD records. The Value field of this
../data/rfc/rfc6733.txt- AVP is the nominal interval between these records in seconds.
../data/rfc/rfc6733.txt: The Diameter node that originates the accounting information,
../data/rfc/rfc6733.txt- known as the client, MUST produce the first INTERIM_RECORD record
../data/rfc/rfc6733.txt- roughly at the time when this nominal interval has elapsed from
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
--
../data/rfc/rfc6733.txt- the START_RECORD, the next one again as the interval has elapsed
../data/rfc/rfc6733.txt- once more, and so on until the session ends and a STOP_RECORD
../data/rfc/rfc6733.txt- record is produced.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- The client MUST ensure that the interim record production times
../data/rfc/rfc6733.txt: are randomized so that large accounting message storms are not
../data/rfc/rfc6733.txt- created either among records or around a common service start
../data/rfc/rfc6733.txt- time.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt:9.8.3. Accounting-Record-Number AVP
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: The Accounting-Record-Number AVP (AVP Code 485) is of type Unsigned32
../data/rfc/rfc6733.txt- and identifies this record within one session. As Session-Id AVPs
../data/rfc/rfc6733.txt: are globally unique, the combination of Session-Id and Accounting-
../data/rfc/rfc6733.txt- Record-Number AVPs is also globally unique and can be used in
../data/rfc/rfc6733.txt: matching accounting records with confirmations. An easy way to
../data/rfc/rfc6733.txt- produce unique numbers is to set the value to 0 for records of type
../data/rfc/rfc6733.txt- EVENT_RECORD and START_RECORD and set the value to 1 for the first
../data/rfc/rfc6733.txt- INTERIM_RECORD, 2 for the second, and so on until the value for
../data/rfc/rfc6733.txt- STOP_RECORD is one more than for the last INTERIM_RECORD.
../data/rfc/rfc6733.txt-
--
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-9.8.5. Acct-Multi-Session-Id AVP
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- The Acct-Multi-Session-Id AVP (AVP Code 50) is of type UTF8String,
../data/rfc/rfc6733.txt- following the format specified in Section 8.8. The Acct-Multi-
../data/rfc/rfc6733.txt: Session-Id AVP is used to link multiple related accounting sessions,
../data/rfc/rfc6733.txt- where each session would have a unique Session-Id but the same Acct-
../data/rfc/rfc6733.txt- Multi-Session-Id AVP. This AVP MAY be returned by the Diameter
../data/rfc/rfc6733.txt- server in an authorization answer, and it MUST be used in all
../data/rfc/rfc6733.txt: accounting messages for the given session.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt:9.8.6. Accounting-Sub-Session-Id AVP
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: The Accounting-Sub-Session-Id AVP (AVP Code 287) is of type
../data/rfc/rfc6733.txt: Unsigned64 and contains the accounting sub-session identifier. The
../data/rfc/rfc6733.txt- combination of the Session-Id and this AVP MUST be unique per sub-
../data/rfc/rfc6733.txt- session, and the value of this AVP MUST be monotonically increased by
../data/rfc/rfc6733.txt- one for all new sub-sessions. The absence of this AVP implies no
../data/rfc/rfc6733.txt: sub-sessions are in use, with the exception of an Accounting-Request
../data/rfc/rfc6733.txt: whose Accounting-Record-Type is set to STOP_RECORD. A STOP_RECORD
../data/rfc/rfc6733.txt: message with no Accounting-Sub-Session-Id AVP present will signal the
../data/rfc/rfc6733.txt- termination of all sub-sessions for a given Session-Id.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-Fajardo, et al. Standards Track [Page 131]
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-RFC 6733 Diameter Base Protocol October 2012
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt:9.8.7. Accounting-Realtime-Required AVP
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: The Accounting-Realtime-Required AVP (AVP Code 483) is of type
../data/rfc/rfc6733.txt- Enumerated and is sent from the Diameter home authorization server to
../data/rfc/rfc6733.txt: the Diameter client or in the Accounting-Answer from the accounting
../data/rfc/rfc6733.txt- server. The client uses information in this AVP to decide what to do
../data/rfc/rfc6733.txt: if the sending of accounting records to the accounting server has
../data/rfc/rfc6733.txt- been temporarily prevented due to, for instance, a network problem.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- DELIVER_AND_GRANT 1
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- The AVP with Value field set to DELIVER_AND_GRANT means that the
../data/rfc/rfc6733.txt- service MUST only be granted as long as there is a connection to
../data/rfc/rfc6733.txt: an accounting server. Note that the set of alternative accounting
../data/rfc/rfc6733.txt- servers are treated as one server in this sense. Having to move
../data/rfc/rfc6733.txt: the accounting record stream to a backup server is not a reason to
../data/rfc/rfc6733.txt- discontinue the service to the user.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- GRANT_AND_STORE 2
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- The AVP with Value field set to GRANT_AND_STORE means that service
--
../data/rfc/rfc6733.txt- 1+ At least one instance of the AVP MUST be present in the
../data/rfc/rfc6733.txt- message.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-10.1. Base Protocol Command AVP Table
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: The table in this section is limited to the non-Accounting Command
../data/rfc/rfc6733.txt- Codes defined in this specification.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- +-----------------------------------------------+
../data/rfc/rfc6733.txt- | Command Code |
../data/rfc/rfc6733.txt- +---+---+---+---+---+---+---+---+---+---+---+---+
../data/rfc/rfc6733.txt- Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA|
../data/rfc/rfc6733.txt- --------------------+---+---+---+---+---+---+---+---+---+---+---+---+
../data/rfc/rfc6733.txt- Acct-Interim- |0 |0 |0 |0 |0 |0 |0-1|0 |0 |0 |0 |0 |
../data/rfc/rfc6733.txt- Interval | | | | | | | | | | | | |
../data/rfc/rfc6733.txt: Accounting-Realtime-|0 |0 |0 |0 |0 |0 |0-1|0 |0 |0 |0 |0 |
../data/rfc/rfc6733.txt- Required | | | | | | | | | | | | |
../data/rfc/rfc6733.txt- Acct-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
../data/rfc/rfc6733.txt- Auth-Application-Id |0+ |0+ |0 |0 |0 |0 |1 |0 |1 |0 |1 |0 |
../data/rfc/rfc6733.txt- Auth-Grace-Period |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
../data/rfc/rfc6733.txt- Auth-Request-Type |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
--
../data/rfc/rfc6733.txt- Vendor-Id |1 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
../data/rfc/rfc6733.txt- Vendor-Specific- |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
../data/rfc/rfc6733.txt- Application-Id | | | | | | | | | | | | |
../data/rfc/rfc6733.txt- --------------------+---+---+---+---+---+---+---+---+---+---+---+---+
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt:10.2. Accounting AVP Table
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- The table in this section is used to represent which AVPs defined in
../data/rfc/rfc6733.txt: this document are to be present in the Accounting messages. These
../data/rfc/rfc6733.txt- AVP occurrence requirements are guidelines, which may be expanded,
../data/rfc/rfc6733.txt- and/or overridden by application-specific requirements in the
../data/rfc/rfc6733.txt- Diameter applications documents.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
--
../data/rfc/rfc6733.txt- +-----+-----+
../data/rfc/rfc6733.txt- Attribute Name | ACR | ACA |
../data/rfc/rfc6733.txt- ------------------------------+-----+-----+
../data/rfc/rfc6733.txt- Acct-Interim-Interval | 0-1 | 0-1 |
../data/rfc/rfc6733.txt- Acct-Multi-Session-Id | 0-1 | 0-1 |
../data/rfc/rfc6733.txt: Accounting-Record-Number | 1 | 1 |
../data/rfc/rfc6733.txt: Accounting-Record-Type | 1 | 1 |
../data/rfc/rfc6733.txt- Acct-Session-Id | 0-1 | 0-1 |
../data/rfc/rfc6733.txt: Accounting-Sub-Session-Id | 0-1 | 0-1 |
../data/rfc/rfc6733.txt: Accounting-Realtime-Required | 0-1 | 0-1 |
../data/rfc/rfc6733.txt- Acct-Application-Id | 0-1 | 0-1 |
../data/rfc/rfc6733.txt- Auth-Application-Id | 0 | 0 |
../data/rfc/rfc6733.txt- Class | 0+ | 0+ |
../data/rfc/rfc6733.txt- Destination-Host | 0-1 | 0 |
../data/rfc/rfc6733.txt- Destination-Realm | 1 | 0 |
--
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-11.3.2. Result-Code AVP Values
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- New values are available for assignment via IETF Review [RFC5226].
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt:11.3.3. Accounting-Record-Type AVP Values
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- New values are available for assignment via IETF Review [RFC5226].
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-11.3.4. Termination-Cause AVP Values
../data/rfc/rfc6733.txt-
--
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-11.3.11. Re-Auth-Request-Type AVP Values
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- New values are available for assignment via IETF Review [RFC5226].
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt:11.3.12. Accounting-Realtime-Required AVP Values
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- New values are available for assignment via IETF Review [RFC5226].
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-11.3.13. Inband-Security-Id AVP (code 299)
../data/rfc/rfc6733.txt-
--
../data/rfc/rfc6733.txt- keys. The following AVPs defined in this document are considered to
../data/rfc/rfc6733.txt- be security-sensitive:
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- o Acct-Interim-Interval
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: o Accounting-Realtime-Required
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- o Acct-Multi-Session-Id
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: o Accounting-Record-Number
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: o Accounting-Record-Type
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: o Accounting-Session-Id
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: o Accounting-Sub-Session-Id
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- o Class
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
--
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-RFC 6733 Diameter Base Protocol October 2012
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
../data/rfc/rfc6733.txt: Accounting (AAA) Transport Profile", RFC 3539, June 2003.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
../data/rfc/rfc6733.txt- 10646", STD 63, RFC 3629, November 2003.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application
--
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
../data/rfc/rfc6733.txt- "Remote Authentication Dial In User Service (RADIUS)",
../data/rfc/rfc6733.txt- RFC 2865, June 2000.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS
../data/rfc/rfc6733.txt- Extensions", RFC 2869, June 2000.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- [RFC2881] Mitton, D. and M. Beadles, "Network Access Server
../data/rfc/rfc6733.txt- Requirements Next Generation (NASREQNG) NAS Model",
../data/rfc/rfc6733.txt- RFC 2881, July 2000.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction
../data/rfc/rfc6733.txt: to Accounting Management", RFC 2975, October 2000.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- [RFC2989] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann,
../data/rfc/rfc6733.txt- P., Shiino, H., Walsh, P., Zorn, G., Dommety, G.,
../data/rfc/rfc6733.txt- Perkins, C., Patil, B., Mitton, D., Manning, S.,
../data/rfc/rfc6733.txt- Beadles, M., Chen, X., Sivalingham, S., Hameed, A.,
--
../data/rfc/rfc6733.txt- This indicates that the server supports TCP available at the returned
../data/rfc/rfc6733.txt- host names.
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-Appendix C. Duplicate Detection
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: As described in Section 9.4, accounting record duplicate detection is
../data/rfc/rfc6733.txt- based on session identifiers. Duplicates can appear for various
../data/rfc/rfc6733.txt- reasons:
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt- o Failover to an alternate server. Where close to real-time
../data/rfc/rfc6733.txt- performance is required, failover thresholds need to be kept low.
--
../data/rfc/rfc6733.txt-Fajardo, et al. Standards Track [Page 149]
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-RFC 6733 Diameter Base Protocol October 2012
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: it has already tried to send the accounting records in its non-
../data/rfc/rfc6733.txt- volatile memory before the reboot occurred. Diameter servers MAY use
../data/rfc/rfc6733.txt- the T flag as an aid when processing requests and detecting duplicate
../data/rfc/rfc6733.txt- messages. However, servers that do this MUST ensure that duplicates
../data/rfc/rfc6733.txt- are found even when the first transmitted request arrives at the
../data/rfc/rfc6733.txt- server after the retransmitted request. It can be used only in cases
--
../data/rfc/rfc6733.txt- the request is sent again, (e.g., due to a failover to an alternate
../data/rfc/rfc6733.txt- peer, due to a recovered primary peer or due to a client re-sending a
../data/rfc/rfc6733.txt- stored record from non-volatile memory such as after reboot of a
../data/rfc/rfc6733.txt- client or agent).
../data/rfc/rfc6733.txt-
../data/rfc/rfc6733.txt: In some cases, the Diameter accounting server can delay the duplicate
../data/rfc/rfc6733.txt: detection and accounting record processing until a post-processing
../data/rfc/rfc6733.txt- phase takes place. At that time records are likely to be sorted
../data/rfc/rfc6733.txt- according to the included User-Name and duplicate elimination is easy
../data/rfc/rfc6733.txt- in this case. In other situations, it may be necessary to perform
../data/rfc/rfc6733.txt- real-time duplicate detection, such as when credit limits are imposed
../data/rfc/rfc6733.txt- or real-time fraud detection is desired.
--
../data/rfc/rfc6733.txt- increases as the failover interval is decreased. In order to be
../data/rfc/rfc6733.txt- able to detect duplicates that are out of order, the Diameter
../data/rfc/rfc6733.txt- server should use backward and forward time windows when
../data/rfc/rfc6733.txt- performing duplicate checking for the T-flag-marked request. For
../data/rfc/rfc6733.txt- example, in order to allow time for the original record to exit
../data/rfc/rfc6733.txt: the network and be recorded by the accounting server, the Diameter
../data/rfc/rfc6733.txt- server can delay processing records with the T flag set until a
../data/rfc/rfc6733.txt- time period TIME_WAIT + RECORD_PROCESSING_TIME has elapsed after
../data/rfc/rfc6733.txt- the closing of the original transport connection. After this time
../data/rfc/rfc6733.txt- period, it may check the T-flag-marked records against the
../data/rfc/rfc6733.txt- database with relative assurance that the original records, if
--
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt-1. Introduction
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt- The RADIUS protocol [RFC2865] is a widely deployed authentication and
../data/rfc/rfc6614.txt: authorization protocol. The supplementary RADIUS Accounting
../data/rfc/rfc6614.txt: specification [RFC2866] provides accounting mechanisms, thus
../data/rfc/rfc6614.txt: delivering a full Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc6614.txt- solution. However, RADIUS is experiencing several shortcomings, such
../data/rfc/rfc6614.txt- as its dependency on the unreliable transport protocol UDP and the
../data/rfc/rfc6614.txt- lack of security for large parts of its packet payload. RADIUS
../data/rfc/rfc6614.txt- security is based on the MD5 algorithm, which has been proven to be
../data/rfc/rfc6614.txt- insecure.
--
../data/rfc/rfc6614.txt-2. Normative: Transport Layer Security for RADIUS/TCP
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt-2.1. TCP port and Packet Types
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt- The default destination port number for RADIUS over TLS is TCP/2083.
../data/rfc/rfc6614.txt: There are no separate ports for authentication, accounting, and
../data/rfc/rfc6614.txt- dynamic authorization changes. The source port is arbitrary. See
../data/rfc/rfc6614.txt- Section 3.4 for considerations regarding the separation of
../data/rfc/rfc6614.txt: authentication, accounting, and dynamic authorization traffic.
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt-2.2. TLS Negotiation
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt- RADIUS/TLS has no notion of negotiating TLS in an established
../data/rfc/rfc6614.txt- connection. Servers and clients need to be preconfigured to use
--
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt- o TLS Identifier
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt-2.5. RADIUS Datagrams
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt: Authentication, Authorization, and Accounting packets are sent
../data/rfc/rfc6614.txt- according to the following rules:
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt- RADIUS/TLS clients transmit the same packet types on the connection
../data/rfc/rfc6614.txt- they initiated as a RADIUS/UDP client would (see Section 3.4 (3) and
../data/rfc/rfc6614.txt- (4)). For example, they send
--
../data/rfc/rfc6614.txt-RFC 6614 RADIUS over TLS May 2012
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt- o Access-Request
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt: o Accounting-Request
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt- o Status-Server
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt- o Disconnect-ACK
../data/rfc/rfc6614.txt-
--
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt- and they receive
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt- o Access-Accept
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt: o Accounting-Response
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt- o Disconnect-Request
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt- o ...
../data/rfc/rfc6614.txt-
--
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt- o Access-Accept
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt- o Access-Reject
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt: o Accounting-Response
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt- o Disconnect-Request
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt- o ...
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt- and they receive
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt- o Access-Request
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt: o Accounting-Request
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt- o Status-Server
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt- o Disconnect-ACK
../data/rfc/rfc6614.txt-
--
../data/rfc/rfc6614.txt- Request' is received, a RADIUS/TLS server needs to respond with a
../data/rfc/rfc6614.txt- 'CoA-NAK' or 'Disconnect-NAK', respectively. The NAK SHOULD
../data/rfc/rfc6614.txt- contain an attribute Error-Cause with the value 406 ("Unsupported
../data/rfc/rfc6614.txt- Extension"); see [RFC5176] for details.
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt: o When an unwanted packet of type 'Accounting-Request' is received,
../data/rfc/rfc6614.txt: the RADIUS/TLS server SHOULD reply with an Accounting-Response
../data/rfc/rfc6614.txt- containing an Error-Cause attribute with value 406 "Unsupported
../data/rfc/rfc6614.txt: Extension" as defined in [RFC5176]. A RADIUS/TLS accounting
../data/rfc/rfc6614.txt: client receiving such an Accounting-Response SHOULD log the error
../data/rfc/rfc6614.txt: and stop sending Accounting-Request packets.
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt-3. Informative: Design Decisions
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt- This section explains the design decisions that led to the rules
../data/rfc/rfc6614.txt- defined in the previous section.
--
../data/rfc/rfc6614.txt- longer be detected by a differing datagram boundary. See
../data/rfc/rfc6614.txt- Section 2.6.4 of [RFC6613] for more details.
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt- (2) Within RADIUS/UDP [RFC2865], a shared secret is used for hiding
../data/rfc/rfc6614.txt- attributes such as User-Password, as well as in computation of
../data/rfc/rfc6614.txt: the Response Authenticator. In RADIUS accounting [RFC2866], the
../data/rfc/rfc6614.txt- shared secret is used in computation of both the Request
../data/rfc/rfc6614.txt- Authenticator and the Response Authenticator. Since TLS
../data/rfc/rfc6614.txt- provides integrity protection and encryption sufficient to
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt-
--
../data/rfc/rfc6614.txt- necessary to configure a RADIUS shared secret. The use of a
../data/rfc/rfc6614.txt- fixed string for the obsolete shared secret eliminates possible
../data/rfc/rfc6614.txt- node misconfigurations.
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt- (3) RADIUS/UDP [RFC2865] uses different UDP ports for
../data/rfc/rfc6614.txt: authentication, accounting, and dynamic authorization changes.
../data/rfc/rfc6614.txt- RADIUS/TLS allocates a single port for all RADIUS packet types.
../data/rfc/rfc6614.txt- Nevertheless, in RADIUS/TLS, the notion of a client that sends
../data/rfc/rfc6614.txt- authentication requests and processes replies associated with
../data/rfc/rfc6614.txt- its users' sessions and the notion of a server that receives
../data/rfc/rfc6614.txt- requests, processes them, and sends the appropriate replies is
--
../data/rfc/rfc6614.txt- an implementation to actually process these packet types; it is
../data/rfc/rfc6614.txt- only required that the NAK be sent as defined above.
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt- (5) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly
../data/rfc/rfc6614.txt- allocated UDP port to signal that a peer RADIUS server does not
../data/rfc/rfc6614.txt: support the reception and processing of RADIUS Accounting
../data/rfc/rfc6614.txt: packets. There is no RADIUS datagram to signal an Accounting
../data/rfc/rfc6614.txt: NAK. Clients may be misconfigured for sending Accounting
../data/rfc/rfc6614.txt- packets to a RADIUS/TLS server that does not wish to process
../data/rfc/rfc6614.txt: their Accounting packet. To prevent a regression of
../data/rfc/rfc6614.txt: detectability of this situation, the Accounting-Response +
../data/rfc/rfc6614.txt- Error-Cause signaling was introduced.
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt-4. Compatibility with Other RADIUS Transports
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt- The IETF defines multiple alternative transports to the classic UDP
--
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt- [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
../data/rfc/rfc6614.txt- "Remote Authentication Dial In User Service (RADIUS)",
../data/rfc/rfc6614.txt- RFC 2865, June 2000.
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt- [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
../data/rfc/rfc6614.txt- for Transport Layer Security (TLS)", RFC 4279,
../data/rfc/rfc6614.txt- December 2005.
../data/rfc/rfc6614.txt-
--
../data/rfc/rfc6614.txt- [RADEXT-DTLS]
../data/rfc/rfc6614.txt- DeKok, A., "DTLS as a Transport Layer for RADIUS", Work
../data/rfc/rfc6614.txt- in Progress, October 2010.
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt- [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
../data/rfc/rfc6614.txt: Accounting (AAA) Transport Profile", RFC 3539, June 2003.
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt- [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
../data/rfc/rfc6614.txt- Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
../data/rfc/rfc6614.txt-
../data/rfc/rfc6614.txt- [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
--
../data/rfc/rfc8374.txt- [BGPsec-Initial]. However, the ordering of these validation-
../data/rfc/rfc8374.txt- processing steps is not a normative part of the BGPsec specification.
../data/rfc/rfc8374.txt-
../data/rfc/rfc8374.txt- 1. Verify that the signed update is syntactically correct. For
../data/rfc/rfc8374.txt- example, check to see if the number of signatures matches the
../data/rfc/rfc8374.txt: number of ASes in the AS path (after duly accounting for AS
../data/rfc/rfc8374.txt- prepending).
../data/rfc/rfc8374.txt-
../data/rfc/rfc8374.txt- 2. Verify that the origin AS is authorized to advertise the prefix
../data/rfc/rfc8374.txt- in question. This verification is based on data from ROAs and
../data/rfc/rfc8374.txt- does not require any cryptographic operations.
--
../data/rfc/rfc8374.txt- discussions.
../data/rfc/rfc8374.txt-
../data/rfc/rfc8374.txt- E1 Abnormalities where a peer (i.e., the preceding AS) should
../data/rfc/rfc8374.txt- definitely not have propagated to a receiving eBGPsec router.
../data/rfc/rfc8374.txt- For example, (A) the number of signatures does not match the
../data/rfc/rfc8374.txt: number of ASes in the AS path (after accounting for AS
../data/rfc/rfc8374.txt- prepending), (B) there is an AS_SET in the received update and
../data/rfc/rfc8374.txt- the update has signatures, or (C) other syntactic errors with
../data/rfc/rfc8374.txt- signatures have occurred.
../data/rfc/rfc8374.txt-
../data/rfc/rfc8374.txt- Reaction: See Section 8.5.
--
../data/rfc/rfc8374.txt-
../data/rfc/rfc8374.txt-8.5.1. Decision
../data/rfc/rfc8374.txt-
../data/rfc/rfc8374.txt- If there are syntactic-error conditions such as (A) AS_SET and
../data/rfc/rfc8374.txt- BGPsec_PATH both appearing in an update, (B) the number of signatures
../data/rfc/rfc8374.txt: not matching the number of ASes (after accounting for any AS
../data/rfc/rfc8374.txt- prepending), or (C) a parsing issue occurring with the BGPsec_PATH
../data/rfc/rfc8374.txt- attribute, then the update (with the signatures stripped) will still
../data/rfc/rfc8374.txt- be considered in the best-path-selection algorithm. (**Note: This is
../data/rfc/rfc8374.txt- not true in RFC 8205**.) If the update is selected as the best path,
../data/rfc/rfc8374.txt- then the update will be propagated unsigned. The error condition
--
../data/rfc/rfc4089.txt-O>> responsibilities of the IETF Administrative Oversight Committee
../data/rfc/rfc4089.txt-O>> (IAOC), an IETF-selected body responsible for overseeing the
../data/rfc/rfc4089.txt-O>> IASA. Like the Internet Architecture Board (IAB), the IASA would
../data/rfc/rfc4089.txt-O>> be housed within the ISOC legal umbrella. The BCP would also
../data/rfc/rfc4089.txt-O>> describe ISOC's responsibilities within this scenario, including
../data/rfc/rfc4089.txt:O>> requirements for financial accounting and transparency. A draft
../data/rfc/rfc4089.txt-O>> of this BCP is included in the next section of this document.
../data/rfc/rfc4089.txt-O>>
../data/rfc/rfc4089.txt-O>> Scenario O allows us to establish IETF control over our
../data/rfc/rfc4089.txt-O>> administrative support functions in terms of determining that
../data/rfc/rfc4089.txt-O>> they meet the community's needs, and adjusting them from time to
--
../data/rfc/rfc4089.txt-O>> process.
../data/rfc/rfc4089.txt-O>>
../data/rfc/rfc4089.txt-O>>
../data/rfc/rfc4089.txt-O>> November 1 Final budget to the ISOC Board for approval.
../data/rfc/rfc4089.txt-O>>
../data/rfc/rfc4089.txt:O>> The IAD will provide monthly accountings of expenses, and will
../data/rfc/rfc4089.txt-O>> update forecasts of expenditures quarterly. This may necessitate
../data/rfc/rfc4089.txt-O>> the adjustment of the IASA budget. The revised budget will need
../data/rfc/rfc4089.txt-O>> to be approved by the IAOC and ISOC Board of Trustees.
../data/rfc/rfc4089.txt-O>>
../data/rfc/rfc4089.txt-O>> 2.4 Relationship of the IAOC to Existing IETF Leadership
--
../data/rfc/rfc4675.txt- unsupported attribute. It is recommended that an Error-Cause
../data/rfc/rfc4675.txt- attribute with the value set to "Unsupported Attribute" (401) be
../data/rfc/rfc4675.txt- included in the CoA-NAK. As noted in [RFC3576], authorization
../data/rfc/rfc4675.txt- changes are atomic so that this situation does not result in session
../data/rfc/rfc4675.txt- termination and the preexisting configuration remains unchanged. As
../data/rfc/rfc4675.txt: a result, no accounting packets should be generated.
../data/rfc/rfc4675.txt-
../data/rfc/rfc4675.txt-2. Attributes
../data/rfc/rfc4675.txt-
../data/rfc/rfc4675.txt-2.1. Egress-VLANID
../data/rfc/rfc4675.txt-
--
../data/rfc/rfc4675.txt- VLANID included in tunnel attributes. To configure an untagged
../data/rfc/rfc4675.txt- VLAN for both ingress and egress, the tunnel attributes of
../data/rfc/rfc4675.txt- [RFC3580] MUST be used.
../data/rfc/rfc4675.txt-
../data/rfc/rfc4675.txt- Multiple Egress-VLANID attributes MAY be included in Access-
../data/rfc/rfc4675.txt: Request, Access-Accept, CoA-Request, or Accounting-Request
../data/rfc/rfc4675.txt- packets; this attribute MUST NOT be sent within an Access-
../data/rfc/rfc4675.txt- Challenge, Access-Reject, Disconnect-Request, Disconnect-ACK,
../data/rfc/rfc4675.txt-
../data/rfc/rfc4675.txt-
../data/rfc/rfc4675.txt-
--
../data/rfc/rfc4675.txt- per-port variable defined in [IEEE-802.1Q] clause 8.4.5. When the
../data/rfc/rfc4675.txt- attribute has the value "Enabled", the set of VLANs that are
../data/rfc/rfc4675.txt- allowed to ingress a port must match the set of VLANs that are
../data/rfc/rfc4675.txt- allowed to egress a port. Only a single Ingress-Filters attribute
../data/rfc/rfc4675.txt- MAY be sent within an Access-Request, Access-Accept, CoA-Request,
../data/rfc/rfc4675.txt: or Accounting-Request packet; this attribute MUST NOT be sent
../data/rfc/rfc4675.txt- within an Access-Challenge, Access-Reject, Disconnect-Request,
../data/rfc/rfc4675.txt- Disconnect-ACK, Disconnect-NAK, CoA-ACK, or CoA-NAK.
../data/rfc/rfc4675.txt-
../data/rfc/rfc4675.txt- The Ingress-Filters attribute is shown below. The fields are
../data/rfc/rfc4675.txt- transmitted from left to right:
--
../data/rfc/rfc4675.txt- indicates if frames on the VLAN for this port are to be
../data/rfc/rfc4675.txt- represented in tagged or untagged format, the second part is the
../data/rfc/rfc4675.txt- VLAN name.
../data/rfc/rfc4675.txt-
../data/rfc/rfc4675.txt- Multiple Egress-VLAN-Name attributes MAY be included within an
../data/rfc/rfc4675.txt: Access-Request, Access-Accept, CoA-Request, or Accounting-Request
../data/rfc/rfc4675.txt- packet; this attribute MUST NOT be sent within an Access-
../data/rfc/rfc4675.txt- Challenge, Access-Reject, Disconnect-Request, Disconnect-ACK,
../data/rfc/rfc4675.txt- Disconnect-NAK, CoA-ACK, or CoA-NAK. Each attribute adds the
../data/rfc/rfc4675.txt- named VLAN to the list of allowed egress VLANs for the port. The
../data/rfc/rfc4675.txt- Egress-VLAN-Name attribute is shown below. The fields are
--
../data/rfc/rfc4675.txt-
../data/rfc/rfc4675.txt- A single User-Priority-Table attribute MAY be included in an
../data/rfc/rfc4675.txt- Access-Accept or CoA-Request packet; this attribute MUST NOT be
../data/rfc/rfc4675.txt- sent within an Access-Request, Access-Challenge, Access-Reject,
../data/rfc/rfc4675.txt- Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-ACK, CoA-
../data/rfc/rfc4675.txt: NAK or Accounting-Request. Since the regeneration table is only
../data/rfc/rfc4675.txt- maintained by a bridge conforming to [IEEE-802.1D], this attribute
../data/rfc/rfc4675.txt- should only be sent to a RADIUS client supporting that
../data/rfc/rfc4675.txt- specification.
../data/rfc/rfc4675.txt-
../data/rfc/rfc4675.txt- The User-Priority-Table attribute is shown below. The fields are
--
../data/rfc/rfc4675.txt- AA-Answer or Diameter-EAP-Answer messages that indicate failure.
../data/rfc/rfc4675.txt-
../data/rfc/rfc4675.txt- What is said about COA-Request applies in Diameter to Re-Auth-Request
../data/rfc/rfc4675.txt- [RFC4005].
../data/rfc/rfc4675.txt-
../data/rfc/rfc4675.txt: What is said about Accounting-Request applies to Diameter
../data/rfc/rfc4675.txt: Accounting-Request [RFC4005] as well.
../data/rfc/rfc4675.txt-
../data/rfc/rfc4675.txt-5. IANA Considerations
../data/rfc/rfc4675.txt-
../data/rfc/rfc4675.txt- This specification does not create any new registries.
../data/rfc/rfc4675.txt-
--
../data/rfc/rfc4675.txt- 59 - User-Priority-Table
../data/rfc/rfc4675.txt-
../data/rfc/rfc4675.txt-6. Security Considerations
../data/rfc/rfc4675.txt-
../data/rfc/rfc4675.txt- This specification describes the use of RADIUS and Diameter for
../data/rfc/rfc4675.txt: purposes of authentication, authorization, and accounting in IEEE 802
../data/rfc/rfc4675.txt- local area networks. RADIUS threats and security issues for this
../data/rfc/rfc4675.txt- application are described in [RFC3579] and [RFC3580]; security issues
../data/rfc/rfc4675.txt- encountered in roaming are described in [RFC2607]. For Diameter, the
../data/rfc/rfc4675.txt- security issues relating to this application are described in
../data/rfc/rfc4675.txt- [RFC4005] and [RFC4072].
--
../data/rfc/rfc1478.txt- routing entity may select routes that are specific to certain source
../data/rfc/rfc1478.txt- domains, provided that the routing entity has access to the source
../data/rfc/rfc1478.txt- policies of those domains.
../data/rfc/rfc1478.txt-
../data/rfc/rfc1478.txt- In the distance vector context, the flexibility of policy route
../data/rfc/rfc1478.txt: generation afforded by accounting for other domains' transit and
../data/rfc/rfc1478.txt- source policies in route selection has the following disadvantages:
../data/rfc/rfc1478.txt-
../data/rfc/rfc1478.txt- - Each recipient of a distance vector message must bear the cost of
../data/rfc/rfc1478.txt- verifying the consistency of the associated route with the
../data/rfc/rfc1478.txt- constituent domains' transit policies.
--
../data/rfc/rfc1478.txt-3.2.1. Path Agents
../data/rfc/rfc1478.txt-
../data/rfc/rfc1478.txt- Any Internet host can reap the benefits of IDPR, as long as there
../data/rfc/rfc1478.txt- exists a path agent configured to act on its behalf and a means by
../data/rfc/rfc1478.txt- which the host's messages can reach that path agent. Path agents
../data/rfc/rfc1478.txt: select and set up policy routes for hosts, accounting for service
../data/rfc/rfc1478.txt- requirements. To obtain a host's service requirements, a path agent
../data/rfc/rfc1478.txt- may either consult its configured IDPR source policy information or
../data/rfc/rfc1478.txt- extract service requirements directly from the host's data messages,
../data/rfc/rfc1478.txt- provided such information is available in these data messages.
../data/rfc/rfc1478.txt-
--
../data/rfc/rfc3220.txt-
../data/rfc/rfc3220.txt- When the mobile node receives an Agent Advertisement with the 'R' bit
../data/rfc/rfc3220.txt- set, the mobile node SHOULD register through the foreign agent, even
../data/rfc/rfc3220.txt- when the mobile node might be able to acquire its own co-located
../data/rfc/rfc3220.txt- care-of address. This feature is intended to allow sites to enforce
../data/rfc/rfc3220.txt: visiting policies (such as accounting) which require exchanges of
../data/rfc/rfc3220.txt- authorization.
../data/rfc/rfc3220.txt-
../data/rfc/rfc3220.txt- If formerly reserved bits require some kind of monitoring/enforcement
../data/rfc/rfc3220.txt- at the foreign link, foreign agents implementing the new
../data/rfc/rfc3220.txt- specification for the formerly reserved bits can set the 'R' bit.
Binary file ../data/rfc/rfc776.txt matches
--
../data/rfc/rfc7270.txt- See "NetFlow Version 9 Flow-Record Format" [CCO-NF9FMT].
../data/rfc/rfc7270.txt-
../data/rfc/rfc7270.txt-4.13. srcTrafficIndex
../data/rfc/rfc7270.txt-
../data/rfc/rfc7270.txt- Description:
../data/rfc/rfc7270.txt: BGP Policy Accounting Source Traffic Index.
../data/rfc/rfc7270.txt-
../data/rfc/rfc7270.txt- Abstract Data Type: unsigned32
../data/rfc/rfc7270.txt-
../data/rfc/rfc7270.txt- ElementId: 92
../data/rfc/rfc7270.txt-
../data/rfc/rfc7270.txt- Semantics: identifier
../data/rfc/rfc7270.txt-
../data/rfc/rfc7270.txt- Status: current
../data/rfc/rfc7270.txt-
../data/rfc/rfc7270.txt- Reference:
../data/rfc/rfc7270.txt: BGP policy accounting as described in [CCO-BGPPOL].
../data/rfc/rfc7270.txt-
../data/rfc/rfc7270.txt-
../data/rfc/rfc7270.txt-
../data/rfc/rfc7270.txt-
../data/rfc/rfc7270.txt-
--
../data/rfc/rfc7270.txt-
../data/rfc/rfc7270.txt-
../data/rfc/rfc7270.txt-4.14. dstTrafficIndex
../data/rfc/rfc7270.txt-
../data/rfc/rfc7270.txt- Description:
../data/rfc/rfc7270.txt: BGP Policy Accounting Destination Traffic Index.
../data/rfc/rfc7270.txt-
../data/rfc/rfc7270.txt- Abstract Data Type: unsigned32
../data/rfc/rfc7270.txt-
../data/rfc/rfc7270.txt- ElementId: 93
../data/rfc/rfc7270.txt-
../data/rfc/rfc7270.txt- Semantics: identifier
../data/rfc/rfc7270.txt-
../data/rfc/rfc7270.txt- Status: current
../data/rfc/rfc7270.txt-
../data/rfc/rfc7270.txt- Reference:
../data/rfc/rfc7270.txt: BGP policy accounting as described in [CCO-BGPPOL].
../data/rfc/rfc7270.txt-
../data/rfc/rfc7270.txt-4.15. className
../data/rfc/rfc7270.txt-
../data/rfc/rfc7270.txt- Description:
../data/rfc/rfc7270.txt- Deprecated in favor of 335 selectorName. Traffic Class Name,
--
../data/rfc/rfc7270.txt- 2013.
../data/rfc/rfc7270.txt-
../data/rfc/rfc7270.txt-8.2. Informative References
../data/rfc/rfc7270.txt-
../data/rfc/rfc7270.txt- [CCO-BGPPOL]
../data/rfc/rfc7270.txt: Cisco, "BGP Policy Accounting and BGP Policy Accounting
../data/rfc/rfc7270.txt: Output Interface Accounting Features", December 2005,
../data/rfc/rfc7270.txt- <http://www.cisco.com/en/US/tech/tk365/
../data/rfc/rfc7270.txt- technologies_tech_note09186a0080094e88.shtml>.
../data/rfc/rfc7270.txt-
../data/rfc/rfc7270.txt- [CCO-MLS] Cisco, "IP MultiLayer Switching Sample Configuration",
../data/rfc/rfc7270.txt- November 2007,
--
../data/rfc/rfc7270.txt- group=""
../data/rfc/rfc7270.txt- dataTypeSemantics="identifier"
../data/rfc/rfc7270.txt- elementId="92" applicability="flow" status="current">
../data/rfc/rfc7270.txt- <description>
../data/rfc/rfc7270.txt- <paragraph>
../data/rfc/rfc7270.txt: BGP Policy Accounting Source Traffic Index.
../data/rfc/rfc7270.txt- </paragraph>
../data/rfc/rfc7270.txt- </description>
../data/rfc/rfc7270.txt- <reference>
../data/rfc/rfc7270.txt: BGP policy accounting as described in
../data/rfc/rfc7270.txt- http://www.cisco.com/en/US/tech/tk365/
../data/rfc/rfc7270.txt- technologies_tech_note09186a0080094e88.shtml
../data/rfc/rfc7270.txt- </reference>
../data/rfc/rfc7270.txt-
../data/rfc/rfc7270.txt-
--
../data/rfc/rfc7270.txt- group=""
../data/rfc/rfc7270.txt- dataTypeSemantics="identifier"
../data/rfc/rfc7270.txt- elementId="93" applicability="flow" status="current">
../data/rfc/rfc7270.txt- <description>
../data/rfc/rfc7270.txt- <paragraph>
../data/rfc/rfc7270.txt: BGP Policy Accounting Destination Traffic Index.
../data/rfc/rfc7270.txt- </paragraph>
../data/rfc/rfc7270.txt- </description>
../data/rfc/rfc7270.txt- <reference>
../data/rfc/rfc7270.txt: BGP policy accounting as described in
../data/rfc/rfc7270.txt- http://www.cisco.com/en/US/tech/tk365/
../data/rfc/rfc7270.txt- technologies_tech_note09186a0080094e88.shtml
../data/rfc/rfc7270.txt- </reference>
../data/rfc/rfc7270.txt- </field>
../data/rfc/rfc7270.txt- <field name="className" dataType="string"
--
../data/rfc/rfc2430.txt-
../data/rfc/rfc2430.txt- Because Priority traffic intrinsically has more 'value' than Best
../data/rfc/rfc2430.txt- Effort traffic, the ability to inject Priority traffic into a network
../data/rfc/rfc2430.txt- must be carefully controlled. Further, signaling concerning Priority
../data/rfc/rfc2430.txt- traffic has to be authenticated because it is likely that the
../data/rfc/rfc2430.txt: signaling information will result in specific accounting and
../data/rfc/rfc2430.txt- eventually billing for the Priority services. ISPs are cautioned to
../data/rfc/rfc2430.txt- insure that the Priority traffic that they accept is in fact from a
../data/rfc/rfc2430.txt- known previous hop. Note that this is a simple requirement to
../data/rfc/rfc2430.txt- fulfill at private peerings, but it is much more difficult at public
../data/rfc/rfc2430.txt- interconnects. For this reason, exchanging Priority traffic at
--
../data/rfc/rfc6320.txt-RFC 6320 ANCP Protocol October 2011
../data/rfc/rfc6320.txt-
../data/rfc/rfc6320.txt-
../data/rfc/rfc6320.txt- * Further description (if any): This may indicate a configuration
../data/rfc/rfc6320.txt- mismatch between the AN and the NAS or Authentication,
../data/rfc/rfc6320.txt: Authorization, and Accounting (AAA).
../data/rfc/rfc6320.txt-
../data/rfc/rfc6320.txt- * Required additional information in the response message: If the
../data/rfc/rfc6320.txt- request identified multiple access lines or the response is a
../data/rfc/rfc6320.txt- Generic Response message, then the response MUST contain a
../data/rfc/rfc6320.txt- Status-Info TLV encapsulating TLV(s) containing the rejected
--
../data/rfc/rfc6320.txt- to the NAS control application that a DSL Port Up or Port Down
../data/rfc/rfc6320.txt- message has been received along with the information contained in the
../data/rfc/rfc6320.txt- message.
../data/rfc/rfc6320.txt-
../data/rfc/rfc6320.txt- The NAS control application updates its view of the DSL access line
../data/rfc/rfc6320.txt: state, performs any required accounting operations, and uses any
../data/rfc/rfc6320.txt- included line attributes to adjust the operation of its queuing/
../data/rfc/rfc6320.txt- scheduling mechanisms as they apply to data passing to and from that
../data/rfc/rfc6320.txt- DSL access line.
../data/rfc/rfc6320.txt-
../data/rfc/rfc6320.txt- Figure 14 summarizes the interaction.
--
../data/rfc/rfc6003.txt-
../data/rfc/rfc6003.txt- o Each CTi value SHOULD correspond 1:1 to the MEF Customer
../data/rfc/rfc6003.txt- Edge VLAN CoS (CE-VLAN CoS).
../data/rfc/rfc6003.txt-
../data/rfc/rfc6003.txt- o The BW requested per CTi field MAY be used for bandwidth
../data/rfc/rfc6003.txt: accounting purposes.
../data/rfc/rfc6003.txt-
../data/rfc/rfc6003.txt- By default, the value of the Index field MUST be set to 0.
../data/rfc/rfc6003.txt-
../data/rfc/rfc6003.txt-
../data/rfc/rfc6003.txt-
--
../data/rfc/rfc1360.txt- for Internet Addressing and Routing
../data/rfc/rfc1360.txt-
../data/rfc/rfc1360.txt- This is an information document and does not specify any
../data/rfc/rfc1360.txt- level of standard.
../data/rfc/rfc1360.txt-
../data/rfc/rfc1360.txt: 1346 - Resource Allocation, Control, and Accounting for the Use of
../data/rfc/rfc1360.txt- Network Resources
../data/rfc/rfc1360.txt-
../data/rfc/rfc1360.txt- This is an information document and does not specify any
../data/rfc/rfc1360.txt- level of standard.
../data/rfc/rfc1360.txt-
--
../data/rfc/rfc681.txt- THREE TERMINALS. PRESENTLY THIS HAS BEEN EXPANDED TO ENCOMPASS A
../data/rfc/rfc681.txt- DH11 TERMINAL MULTIPLEXOR, AN RP03 MOVING HEAD DISK, A TWIN
../data/rfc/rfc681.txt- PLATTER RF11 FIXED HEAD DISK, FLOATING POINT, AND 48K OF CORE.
../data/rfc/rfc681.txt- USER FILES ARE STORED ON THE RP03. THE RF11 IS USED AS A SWAP
../data/rfc/rfc681.txt- DISK AND FOR TEMPORARY FILE STORAGE; ONE RK05 PLATTER CONTAINS
../data/rfc/rfc681.txt: THE SYSTEM FILES, AND THE SECOND CONTAINS LOGIN AND ACCOUNTING
../data/rfc/rfc681.txt- INFORMATION. IN THE NEAR FUTURE, THE SYSTEM WILL BE EXPANDED TO
../data/rfc/rfc681.txt- 128K WORDS OF CORE MEMORY WITH 10 DIAL IN AND 10 HARD WIRED
../data/rfc/rfc681.txt- TERMINAL LINES. 7a
../data/rfc/rfc681.txt-
../data/rfc/rfc681.txt- THE BASE OPERATING SYSTEM OCCUPIES 24.5K WORDS OF MEMORY. THIS
--
../data/rfc/rfc1466.txt-
../data/rfc/rfc1466.txt- The IR may allocate small blocks of Class B network numbers to
../data/rfc/rfc1466.txt- regional registries if so doing will improve the service that is
../data/rfc/rfc1466.txt- being provided to the community. The IR may issue more specific
../data/rfc/rfc1466.txt- guidelines for the further assignment of the numbers which will be
../data/rfc/rfc1466.txt: consistent with the stated guidelines. The IR may require accounting
../data/rfc/rfc1466.txt- of the block assignment including receipt of the applicants'
../data/rfc/rfc1466.txt- engineering plans. The IR may audit these engineering plans to
../data/rfc/rfc1466.txt- confirm that the assignments are consistent with the guidelines.
../data/rfc/rfc1466.txt-
../data/rfc/rfc1466.txt-4.3 Class C
--
../data/rfc/rfc5456.txt- the 'causecode' and 'cause' IEs to specify why registration was
../data/rfc/rfc5456.txt- rejected.
../data/rfc/rfc5456.txt-
../data/rfc/rfc5456.txt- Upon receipt of a REGREJ message, the registrant MUST consider
../data/rfc/rfc5456.txt- registration process unsuccessful and no further interaction is
../data/rfc/rfc5456.txt: required. A peer MAY reinitiate the process at later time accounting
../data/rfc/rfc5456.txt- for potential configuration changes on the registrar or registrant.
../data/rfc/rfc5456.txt-
../data/rfc/rfc5456.txt- Both registrants and registrars MUST be capable of sending and
../data/rfc/rfc5456.txt- processing this message.
../data/rfc/rfc5456.txt-
--
../data/rfc/rfc7831.txt- 4.2. Privacy Aspects of ABFAB Communication Flows ..............36
../data/rfc/rfc7831.txt- 4.2.1. Client to RP .......................................36
../data/rfc/rfc7831.txt- 4.2.2. Client to IdP (via Federation Substrate) ...........37
../data/rfc/rfc7831.txt- 4.2.3. IdP to RP (via Federation Substrate) ...............38
../data/rfc/rfc7831.txt- 4.3. Relationship between User and Entities ....................39
../data/rfc/rfc7831.txt: 4.4. Accounting Information ....................................39
../data/rfc/rfc7831.txt- 4.5. Collection and Retention of Data and Identifiers ..........39
../data/rfc/rfc7831.txt- 4.6. User Participation ........................................40
../data/rfc/rfc7831.txt- 5. Security Considerations ........................................40
../data/rfc/rfc7831.txt- 6. References .....................................................41
../data/rfc/rfc7831.txt- 6.1. Normative References ......................................41
--
../data/rfc/rfc7831.txt- generalized and scaled over the last decade through mechanisms such
../data/rfc/rfc7831.txt- as the Simple Authentication and Security Layer (SASL) with the
../data/rfc/rfc7831.txt- Generic Security Server Application Program Interface (GSS-API)
../data/rfc/rfc7831.txt- (known as the GS2 family) [RFC5801]; the Security Assertion Markup
../data/rfc/rfc7831.txt- Language (SAML) [OASIS.saml-core-2.0-os]; and the Authentication,
../data/rfc/rfc7831.txt: Authorization, and Accounting (AAA) architecture as embodied in
../data/rfc/rfc7831.txt- RADIUS [RFC2865] and Diameter [RFC6733].
../data/rfc/rfc7831.txt-
../data/rfc/rfc7831.txt- A Relying Party (RP) is the entity that manages access to some
../data/rfc/rfc7831.txt- resource. The entity that is requesting access to that resource is
../data/rfc/rfc7831.txt- often described as the client. Many security mechanisms are
--
../data/rfc/rfc7831.txt- support mutual authentication, then there are no guarantees that the
../data/rfc/rfc7831.txt- IdP is who it claims to be, and thus the full NAI, including a
../data/rfc/rfc7831.txt- username and a realm, might be sent to any entity masquerading as a
../data/rfc/rfc7831.txt- particular IdP.
../data/rfc/rfc7831.txt-
../data/rfc/rfc7831.txt: Note that ABFAB has not specified any AAA accounting requirements.
../data/rfc/rfc7831.txt: Implementations that use the accounting portion of AAA should
../data/rfc/rfc7831.txt- consider privacy appropriately when designing this aspect.
../data/rfc/rfc7831.txt-
../data/rfc/rfc7831.txt-4.2.3. IdP to RP (via Federation Substrate)
../data/rfc/rfc7831.txt-
../data/rfc/rfc7831.txt- In this phase, the IdP communicates with the RP, informing it as to
--
../data/rfc/rfc7831.txt- may, however). Knowledge of attribute information about
../data/rfc/rfc7831.txt- Individuals for these entities is not necessary, and thus such
../data/rfc/rfc7831.txt- information should be protected in such a way as to prevent the
../data/rfc/rfc7831.txt- possibility of access to this information.
../data/rfc/rfc7831.txt-
../data/rfc/rfc7831.txt:4.4. Accounting Information
../data/rfc/rfc7831.txt-
../data/rfc/rfc7831.txt- Alongside the core authentication and authorization that occur in AAA
../data/rfc/rfc7831.txt: communications, accounting information about resource consumption may
../data/rfc/rfc7831.txt: be delivered as part of the accounting exchange during the lifetime
../data/rfc/rfc7831.txt- of the granted application session.
../data/rfc/rfc7831.txt-
../data/rfc/rfc7831.txt-4.5. Collection and Retention of Data and Identifiers
../data/rfc/rfc7831.txt-
../data/rfc/rfc7831.txt- In cases where RPs are not required to identify a particular
--
../data/rfc/rfc7778.txt- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
../data/rfc/rfc7778.txt- 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4
../data/rfc/rfc7778.txt- 2. ConEx Use Cases in Mobile Communication Networks . . . . . . 4
../data/rfc/rfc7778.txt- 2.1. ConEx as a Basis for Traffic Management . . . . . . . . . 5
../data/rfc/rfc7778.txt- 2.2. ConEx to Incentivize Scavenger Transports . . . . . . . . 7
../data/rfc/rfc7778.txt: 2.3. Accounting for Congestion Volume . . . . . . . . . . . . 7
../data/rfc/rfc7778.txt- 2.4. Partial vs. Full Deployment . . . . . . . . . . . . . . . 8
../data/rfc/rfc7778.txt- 2.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9
../data/rfc/rfc7778.txt- 3. ConEx in the EPS . . . . . . . . . . . . . . . . . . . . . . 9
../data/rfc/rfc7778.txt- 3.1. Possible Deployment Scenarios . . . . . . . . . . . . . . 9
../data/rfc/rfc7778.txt- 3.2. Implementing ConEx Functions in the EPS . . . . . . . . . 14
--
../data/rfc/rfc7778.txt- 2. It can reduce the need for complex DPI by allowing for a bulk
../data/rfc/rfc7778.txt- packet traffic management system that does not have to consider
../data/rfc/rfc7778.txt- either the application classes flows belong to or the individual
../data/rfc/rfc7778.txt- sessions. Instead, traffic management would be based on the
../data/rfc/rfc7778.txt- current cost (contribution to congestion) incurred by different
../data/rfc/rfc7778.txt: flows and enable operators to apply policing/accounting depending
../data/rfc/rfc7778.txt- on their preference. Such traffic management would be simpler
../data/rfc/rfc7778.txt- and more robust (no real-time flow application type
../data/rfc/rfc7778.txt- identification required, no static configuration of application
../data/rfc/rfc7778.txt- classes); it would also perform better as decisions can be made
../data/rfc/rfc7778.txt- based on real-time actual cost contribution. With ConEx,
--
../data/rfc/rfc7778.txt- impose different QoS for different application sessions; and
../data/rfc/rfc7778.txt-
../data/rfc/rfc7778.txt- B. as a tool to let applications decide on their response to
../data/rfc/rfc7778.txt- congestion notification while incentivizing them to react (in
../data/rfc/rfc7778.txt- general) appropriately, e.g., by enforcing overall limits for
../data/rfc/rfc7778.txt: congestion contribution or by accounting and charging for
../data/rfc/rfc7778.txt- such congestion contribution. Note that this level of
../data/rfc/rfc7778.txt- responsiveness would be on a different level than, say,
../data/rfc/rfc7778.txt- application-layer responsiveness in protocols such as Dynamic
../data/rfc/rfc7778.txt- Adaptive Streaming over HTTP (DASH) [dash]; however, it could
../data/rfc/rfc7778.txt- interwork with such protocols, for example, by triggering
--
../data/rfc/rfc7778.txt- scheme, e.g., by giving a larger bandwidth allowance to users that
../data/rfc/rfc7778.txt- contribute less to congestion or lowering the next monthly
../data/rfc/rfc7778.txt- subscription fee. In principle, this would be possible to implement
../data/rfc/rfc7778.txt- with current specifications.
../data/rfc/rfc7778.txt-
../data/rfc/rfc7778.txt:2.3. Accounting for Congestion Volume
../data/rfc/rfc7778.txt-
../data/rfc/rfc7778.txt: 3G and LTE networks provide extensive support for accounting and
../data/rfc/rfc7778.txt- charging already, for example, see the Policy Charging Control (PCC)
../data/rfc/rfc7778.txt- architecture [TS23203]. In fact, most operators today account
../data/rfc/rfc7778.txt- transmitted data volume on a very fine granular basis and either
../data/rfc/rfc7778.txt- correlate monthly charging to the exact number of packets/bytes
../data/rfc/rfc7778.txt- transmitted or employ some form of flat rate (or flexible flat rate),
../data/rfc/rfc7778.txt- often with a so-called fair-use policy. With such policies, users
../data/rfc/rfc7778.txt- are typically limited to an administratively configured maximum
../data/rfc/rfc7778.txt- bandwidth limit after they have used up their contractual data volume
../data/rfc/rfc7778.txt- budget for the charging period.
../data/rfc/rfc7778.txt-
../data/rfc/rfc7778.txt: Changing this data from volume-based accounting to congestion-based
../data/rfc/rfc7778.txt: accounting would be possible in principle, especially since there
../data/rfc/rfc7778.txt: already is an elaborate per-user accounting system available. Also,
../data/rfc/rfc7778.txt- an operator-provided mobile communication network can be seen as a
../data/rfc/rfc7778.txt- network domain that would allow for such congestion volume
../data/rfc/rfc7778.txt: accounting. This would not require any support from the global
../data/rfc/rfc7778.txt- Internet, especially since the typical scarce resources such as the
../data/rfc/rfc7778.txt-
../data/rfc/rfc7778.txt-
../data/rfc/rfc7778.txt-
../data/rfc/rfc7778.txt-Kutscher, et al. Informational [Page 7]
--
../data/rfc/rfc7778.txt-
../data/rfc/rfc7778.txt- wireless access and the mobile backhaul are all within this domain.
../data/rfc/rfc7778.txt- Traffic normally leaves/enters the operator's network via well-
../data/rfc/rfc7778.txt- defined egress/ingress points that would be ideal candidates for
../data/rfc/rfc7778.txt- policing functions. Moreover, in most commercially operated
../data/rfc/rfc7778.txt: networks, accounting is performed for both received and sent data,
../data/rfc/rfc7778.txt: which would facilitate congestion volume accounting as well.
../data/rfc/rfc7778.txt-
../data/rfc/rfc7778.txt- With respect to the current Path Computation Client (PCC) framework,
../data/rfc/rfc7778.txt: accounting for congestion volume could be added as another feature to
../data/rfc/rfc7778.txt- the "Usage Monitoring Control" capability that is currently based on
../data/rfc/rfc7778.txt- data volume. This would not require a new interface (reference
../data/rfc/rfc7778.txt- points) at all.
../data/rfc/rfc7778.txt-
../data/rfc/rfc7778.txt-2.4. Partial vs. Full Deployment
--
../data/rfc/rfc7778.txt- Since mobile communication networks are multi-vendor networks,
../data/rfc/rfc7778.txt- standardizing ConEx support on UEs (e.g., in 3GPP specifications)
../data/rfc/rfc7778.txt- appears useful. Still, not all UEs would have to support ConEx, and
../data/rfc/rfc7778.txt- operators would be free to choose their policing approach in such
../data/rfc/rfc7778.txt- deployment scenarios. Leveraging existing PCC architectures, 3GPP
../data/rfc/rfc7778.txt: network operators could, for example, decide policing/accounting
../data/rfc/rfc7778.txt- approaches per UE -- i.e., apply fixed volume caps for non-ConEx UEs
../data/rfc/rfc7778.txt- and more flexible schemes for ConEx-enabled UEs.
../data/rfc/rfc7778.txt-
../data/rfc/rfc7778.txt- Moreover, it should be noted that network support for ConEx is a
../data/rfc/rfc7778.txt- feature that some operators may choose to deploy if they wish, but it
--
../data/rfc/rfc7778.txt- requiring any change on UEs.
../data/rfc/rfc7778.txt-
../data/rfc/rfc7778.txt- 2. ConEx is universally employed between operators (as depicted in
../data/rfc/rfc7778.txt- Figure 2) with an end-to-end ConEx feedback loop. Here,
../data/rfc/rfc7778.txt- operators could still employ local policies, congestion
../data/rfc/rfc7778.txt: accounting schemes, etc., and they could use information about
../data/rfc/rfc7778.txt- congestion contribution for determining interconnection
../data/rfc/rfc7778.txt- agreements. This deployment scenario would imply the willingness
../data/rfc/rfc7778.txt- of operators to expose congestion to each other.
../data/rfc/rfc7778.txt-
../data/rfc/rfc7778.txt- 3. For Isolated ConEx domains as depicted in Figure 3, ConEx is
--
../data/rfc/rfc7778.txt- end-to-end congestion exposure. This could be the case when
../data/rfc/rfc7778.txt- ConEx is only implemented in a few networks or when operators
../data/rfc/rfc7778.txt- decide to not expose ECN and account for congestion for inter-
../data/rfc/rfc7778.txt- domain traffic. Independent of the actual scenario, it is likely
../data/rfc/rfc7778.txt- that there will be border gateways (as in today's deployments)
../data/rfc/rfc7778.txt: that are associated with policing and accounting functions.
../data/rfc/rfc7778.txt-
../data/rfc/rfc7778.txt- 4. [conex-lite] describes an approach called "ConEx Lite" for mobile
../data/rfc/rfc7778.txt- networks that is intended for initial deployment of congestion
../data/rfc/rfc7778.txt- exposure concepts in LTE, specifically in the backhaul and core
../data/rfc/rfc7778.txt- network segments. As depicted in Figure 4, ConEx Lite allows a
--
../data/rfc/rfc7778.txt- depicted in Figure 1), operators can have different requirements for
../data/rfc/rfc7778.txt- policing traffic. Although policing is, in principle, location-
../data/rfc/rfc7778.txt- agnostic, it is important to consider requirements related to the EPS
../data/rfc/rfc7778.txt- architecture (Figure 5) such as tunneling between P-GWs and eNBs.
../data/rfc/rfc7778.txt- Policing can require access to subscriber information (e.g.,
../data/rfc/rfc7778.txt: congestion contribution quota) or user-specific accounting, which
../data/rfc/rfc7778.txt- suggests that the ConEx function could be co-located with the P-GW
../data/rfc/rfc7778.txt- that already has an interface towards the Policy and Charging Rule
../data/rfc/rfc7778.txt- Function (PCRF).
../data/rfc/rfc7778.txt-
../data/rfc/rfc7778.txt- Still, policing can serve different purposes. For example, if the
--
../data/rfc/rfc5921.txt- CM Configuration Management
../data/rfc/rfc5921.txt- CO-CS Connection Oriented - Circuit Switched
../data/rfc/rfc5921.txt- CO-PS Connection Oriented - Packet Switched
../data/rfc/rfc5921.txt- DCN Data Communication Network
../data/rfc/rfc5921.txt- EMF Equipment Management Function
../data/rfc/rfc5921.txt: FCAPS Fault, Configuration, Accounting, Performance, and
../data/rfc/rfc5921.txt- Security
../data/rfc/rfc5921.txt- FM Fault Management
../data/rfc/rfc5921.txt- G-ACh Generic Associated Channel
../data/rfc/rfc5921.txt- GAL G-ACh Label
../data/rfc/rfc5921.txt- LER Label Edge Router
--
../data/rfc/rfc5921.txt- o An IP encapsulation where IP capabilities are present, e.g., PW
../data/rfc/rfc5921.txt- ACH encapsulation with IP headers for VCCV-BFD [RFC5885] or IP
../data/rfc/rfc5921.txt- encapsulation for MPLS BFD [RFC5884].
../data/rfc/rfc5921.txt-
../data/rfc/rfc5921.txt- MPLS-TP makes use of such a generic associated channel (G-ACh) to
../data/rfc/rfc5921.txt: support Fault, Configuration, Accounting, Performance, and Security
../data/rfc/rfc5921.txt- (FCAPS) functions by carrying packets related to OAM, a protocol used
../data/rfc/rfc5921.txt- to coordinate path protection state, SCC, MCC or other packet types
../data/rfc/rfc5921.txt- in-band over LSPs, PWs, or sections. The G-ACh is defined in
../data/rfc/rfc5921.txt- [RFC5586] and is similar to the Pseudowire Associated Channel
../data/rfc/rfc5921.txt- [RFC4385], which is used to carry OAM packets over pseudowires. The
--
../data/rfc/rfc1259.txt- function as a channel for delivery of a wide range of privately-
../data/rfc/rfc1259.txt- developed information services. To
../data/rfc/rfc1259.txt-
../data/rfc/rfc1259.txt- encourage use of the Network by commercial information service
../data/rfc/rfc1259.txt- providers, where technically feasible, the Network shall have
../data/rfc/rfc1259.txt: accounting mechanisms which allow, where appropriate, users or
../data/rfc/rfc1259.txt- groups of users to be charged for their usage of copyrighted
../data/rfc/rfc1259.txt- materials over the Network. (5)
../data/rfc/rfc1259.txt-
../data/rfc/rfc1259.txt- Congress can create an environment that stimulates information
../data/rfc/rfc1259.txt- entrepreneurship by mandating that the NREN rely on open technical
--
../data/rfc/rfc1596.txt- 4. Object Definitions .................................... 12
../data/rfc/rfc1596.txt- 4.1 The Frame Relay Service Logical Port Group ........... 12
../data/rfc/rfc1596.txt- 4.2 The Frame Relay Management VC Signaling Group ........ 15
../data/rfc/rfc1596.txt- 4.3 The PVC End-Point Group .............................. 22
../data/rfc/rfc1596.txt- 4.4 Frame Relay PVC Connection Group ..................... 30
../data/rfc/rfc1596.txt: 4.5 Frame Relay Accounting Groups ........................ 37
../data/rfc/rfc1596.txt- 5. Frame Relay Network Service TRAPS ..................... 40
../data/rfc/rfc1596.txt- 6. Conformance Information ............................... 43
../data/rfc/rfc1596.txt- 7. Acknowledgments ....................................... 45
../data/rfc/rfc1596.txt- 8. References ............................................ 45
../data/rfc/rfc1596.txt- 9. Security Considerations ............................... 46
--
../data/rfc/rfc1596.txt-Frame Relay Service MIB Working Group [Page 36]
../data/rfc/rfc1596.txt-
../data/rfc/rfc1596.txt-RFC 1596 Frame Relay Service MIB March 1994
../data/rfc/rfc1596.txt-
../data/rfc/rfc1596.txt-
../data/rfc/rfc1596.txt: -- The Frame Relay Accounting Groups
../data/rfc/rfc1596.txt-
../data/rfc/rfc1596.txt- -- The groups are the following:
../data/rfc/rfc1596.txt: -- Accounting on a PVC basis
../data/rfc/rfc1596.txt: -- Accounting on an Interface/Logical Port basis
../data/rfc/rfc1596.txt-
../data/rfc/rfc1596.txt: -- The Accounting on a Frame Relay PVC basis Group
../data/rfc/rfc1596.txt-
../data/rfc/rfc1596.txt: -- The accounting information is collected for a PVC
../data/rfc/rfc1596.txt- -- segment end-point.
../data/rfc/rfc1596.txt-
../data/rfc/rfc1596.txt- frAccountPVCTable OBJECT-TYPE
../data/rfc/rfc1596.txt- SYNTAX SEQUENCE OF FrAccountPVCEntry
../data/rfc/rfc1596.txt- MAX-ACCESS not-accessible
../data/rfc/rfc1596.txt- STATUS current
../data/rfc/rfc1596.txt- DESCRIPTION
../data/rfc/rfc1596.txt: "The Frame Relay Accounting PVC table. This table
../data/rfc/rfc1596.txt: is used to perform accounting on a PVC segment
../data/rfc/rfc1596.txt- end-point basis."
../data/rfc/rfc1596.txt- ::= { frnetservObjects 6 }
../data/rfc/rfc1596.txt-
../data/rfc/rfc1596.txt- frAccountPVCEntry OBJECT-TYPE
../data/rfc/rfc1596.txt- SYNTAX FrAccountPVCEntry
../data/rfc/rfc1596.txt- MAX-ACCESS not-accessible
../data/rfc/rfc1596.txt- STATUS current
../data/rfc/rfc1596.txt- DESCRIPTION
../data/rfc/rfc1596.txt: "An entry in the Frame Relay Accounting PVC
../data/rfc/rfc1596.txt- table."
../data/rfc/rfc1596.txt- INDEX { ifIndex, frAccountPVCDLCIIndex }
../data/rfc/rfc1596.txt- ::= { frAccountPVCTable 1 }
../data/rfc/rfc1596.txt-
../data/rfc/rfc1596.txt- FrAccountPVCEntry ::=
--
../data/rfc/rfc1596.txt- "The value of this object is equal to the number
../data/rfc/rfc1596.txt- of segments sent by this PVC segment end-point."
../data/rfc/rfc1596.txt- ::= { frAccountPVCEntry 4 }
../data/rfc/rfc1596.txt-
../data/rfc/rfc1596.txt-
../data/rfc/rfc1596.txt: -- The Accounting on a Frame Relay Logical Port basis Group
../data/rfc/rfc1596.txt-
../data/rfc/rfc1596.txt-
../data/rfc/rfc1596.txt- frAccountLportTable OBJECT-TYPE
../data/rfc/rfc1596.txt- SYNTAX SEQUENCE OF FrAccountLportEntry
../data/rfc/rfc1596.txt- MAX-ACCESS not-accessible
../data/rfc/rfc1596.txt- STATUS current
../data/rfc/rfc1596.txt- DESCRIPTION
../data/rfc/rfc1596.txt: "The Frame Relay Accounting Logical Port table.
../data/rfc/rfc1596.txt: This table is used to perform accounting on a
../data/rfc/rfc1596.txt- UNI/NNI Logical Port basis."
../data/rfc/rfc1596.txt- ::= { frnetservObjects 7 }
../data/rfc/rfc1596.txt-
../data/rfc/rfc1596.txt- frAccountLportEntry OBJECT-TYPE
../data/rfc/rfc1596.txt-
--
../data/rfc/rfc1596.txt-
../data/rfc/rfc1596.txt- SYNTAX FrAccountLportEntry
../data/rfc/rfc1596.txt- MAX-ACCESS not-accessible
../data/rfc/rfc1596.txt- STATUS current
../data/rfc/rfc1596.txt- DESCRIPTION
../data/rfc/rfc1596.txt: "An entry in the Frame Relay Accounting Logical
../data/rfc/rfc1596.txt- Port table."
../data/rfc/rfc1596.txt- INDEX { ifIndex }
../data/rfc/rfc1596.txt- ::= { frAccountLportTable 1 }
../data/rfc/rfc1596.txt-
../data/rfc/rfc1596.txt- FrAccountLportEntry ::=
--
../data/rfc/rfc1596.txt-
../data/rfc/rfc1596.txt- GROUP frnetservAccountPVCGroup
../data/rfc/rfc1596.txt- DESCRIPTION
../data/rfc/rfc1596.txt- "This group is optional for Frame Relay interfaces.
../data/rfc/rfc1596.txt- It is
../data/rfc/rfc1596.txt: mandatory if and only if accounting is performed
../data/rfc/rfc1596.txt- on a PVC
../data/rfc/rfc1596.txt- basis this
../data/rfc/rfc1596.txt- Frame Relay interface."
../data/rfc/rfc1596.txt-
../data/rfc/rfc1596.txt- GROUP frnetservAccountLportGroup
--
../data/rfc/rfc1596.txt-
../data/rfc/rfc1596.txt-
../data/rfc/rfc1596.txt- DESCRIPTION
../data/rfc/rfc1596.txt- "This group is optional for Frame Relay interfaces.
../data/rfc/rfc1596.txt- It is
../data/rfc/rfc1596.txt: mandatory if and only if accounting is
../data/rfc/rfc1596.txt- performed on a
../data/rfc/rfc1596.txt- logical port basis this
../data/rfc/rfc1596.txt- Frame Relay interface."
../data/rfc/rfc1596.txt-
../data/rfc/rfc1596.txt- OBJECT frPVCEndptInMaxFrameSize
--
../data/rfc/rfc1596.txt- frnetservAccountPVCGroup OBJECT-GROUP
../data/rfc/rfc1596.txt- OBJECTS { frAccountPVCSegmentSize, frAccountPVCInSegments,
../data/rfc/rfc1596.txt- frAccountPVCOutSegments }
../data/rfc/rfc1596.txt- STATUS current
../data/rfc/rfc1596.txt- DESCRIPTION
../data/rfc/rfc1596.txt: "A collection of objects providing accounting
../data/rfc/rfc1596.txt- information application
../data/rfc/rfc1596.txt- to a Frame Relay PVC end-point."
../data/rfc/rfc1596.txt- ::= { frnetservGroups 5 }
../data/rfc/rfc1596.txt-
../data/rfc/rfc1596.txt- frnetservAccountLportGroup OBJECT-GROUP
../data/rfc/rfc1596.txt- OBJECTS { frAccountLportSegmentSize, frAccountLportInSegments,
../data/rfc/rfc1596.txt- frAccountLportOutSegments }
../data/rfc/rfc1596.txt- STATUS current
../data/rfc/rfc1596.txt- DESCRIPTION
../data/rfc/rfc1596.txt: "A collection of objects providing accounting
../data/rfc/rfc1596.txt- information application
../data/rfc/rfc1596.txt- to a Frame Relay logical port."
../data/rfc/rfc1596.txt- ::= { frnetservGroups 6 }
../data/rfc/rfc1596.txt-
../data/rfc/rfc1596.txt-
--
../data/rfc/rfc2954.txt-
../data/rfc/rfc2954.txt-
../data/rfc/rfc2954.txt- 3.2 Frame Relay Management VC Signaling ........................ 22
../data/rfc/rfc2954.txt- 3.3 Frame Relay PVC End-Points ................................. 32
../data/rfc/rfc2954.txt- 3.4 Frame Relay PVC Connections ................................ 45
../data/rfc/rfc2954.txt: 3.5 Frame Relay Accounting ..................................... 53
../data/rfc/rfc2954.txt- 3.6 Frame Relay Network Service Notifications .................. 56
../data/rfc/rfc2954.txt- 3.7 Conformance Information .................................... 57
../data/rfc/rfc2954.txt- 4 Acknowledgments .............................................. 67
../data/rfc/rfc2954.txt- 5 References ................................................... 67
../data/rfc/rfc2954.txt- 6 Security Considerations ...................................... 69
--
../data/rfc/rfc2954.txt- "This is a system supplied textual representation
../data/rfc/rfc2954.txt- of PVC. It is assigned by the service provider."
../data/rfc/rfc2954.txt- ::= { frPVCConnectEntry 13 }
../data/rfc/rfc2954.txt-
../data/rfc/rfc2954.txt- --
../data/rfc/rfc2954.txt: -- The Frame Relay Accounting
../data/rfc/rfc2954.txt- --
../data/rfc/rfc2954.txt-
../data/rfc/rfc2954.txt- frAccountPVCTable OBJECT-TYPE
../data/rfc/rfc2954.txt- SYNTAX SEQUENCE OF FrAccountPVCEntry
../data/rfc/rfc2954.txt- MAX-ACCESS not-accessible
../data/rfc/rfc2954.txt- STATUS current
../data/rfc/rfc2954.txt- DESCRIPTION
../data/rfc/rfc2954.txt: "The Frame Relay Accounting PVC table. This table
../data/rfc/rfc2954.txt: is used to perform accounting on a PVC segment
../data/rfc/rfc2954.txt- end-point basis."
../data/rfc/rfc2954.txt- ::= { frnetservObjects 6 }
../data/rfc/rfc2954.txt-
../data/rfc/rfc2954.txt- frAccountPVCEntry OBJECT-TYPE
../data/rfc/rfc2954.txt- SYNTAX FrAccountPVCEntry
../data/rfc/rfc2954.txt- MAX-ACCESS not-accessible
../data/rfc/rfc2954.txt- STATUS current
../data/rfc/rfc2954.txt- DESCRIPTION
../data/rfc/rfc2954.txt: "An entry in the Frame Relay Accounting PVC
../data/rfc/rfc2954.txt- table."
../data/rfc/rfc2954.txt- INDEX { ifIndex,
../data/rfc/rfc2954.txt- frAccountPVCDLCIIndex }
../data/rfc/rfc2954.txt- ::= { frAccountPVCTable 1 }
../data/rfc/rfc2954.txt-
--
../data/rfc/rfc2954.txt- "The value of this object is equal to the number
../data/rfc/rfc2954.txt- of segments sent by this PVC segment end-point."
../data/rfc/rfc2954.txt- ::= { frAccountPVCEntry 4 }
../data/rfc/rfc2954.txt-
../data/rfc/rfc2954.txt- --
../data/rfc/rfc2954.txt: -- Accounting on a Frame Relay Logical Port
../data/rfc/rfc2954.txt- --
../data/rfc/rfc2954.txt-
../data/rfc/rfc2954.txt- frAccountLportTable OBJECT-TYPE
../data/rfc/rfc2954.txt- SYNTAX SEQUENCE OF FrAccountLportEntry
../data/rfc/rfc2954.txt- MAX-ACCESS not-accessible
../data/rfc/rfc2954.txt- STATUS current
../data/rfc/rfc2954.txt- DESCRIPTION
../data/rfc/rfc2954.txt: "The Frame Relay Accounting Logical Port table.
../data/rfc/rfc2954.txt: This table is used to perform accounting on a
../data/rfc/rfc2954.txt- UNI/NNI Logical Port basis."
../data/rfc/rfc2954.txt- ::= { frnetservObjects 7 }
../data/rfc/rfc2954.txt-
../data/rfc/rfc2954.txt-
../data/rfc/rfc2954.txt-
--
../data/rfc/rfc2954.txt- frAccountLportEntry OBJECT-TYPE
../data/rfc/rfc2954.txt- SYNTAX FrAccountLportEntry
../data/rfc/rfc2954.txt- MAX-ACCESS not-accessible
../data/rfc/rfc2954.txt- STATUS current
../data/rfc/rfc2954.txt- DESCRIPTION
../data/rfc/rfc2954.txt: "An entry in the Frame Relay Accounting Logical
../data/rfc/rfc2954.txt- Port table."
../data/rfc/rfc2954.txt- INDEX { ifIndex }
../data/rfc/rfc2954.txt- ::= { frAccountLportTable 1 }
../data/rfc/rfc2954.txt-
../data/rfc/rfc2954.txt- FrAccountLportEntry ::=
--
../data/rfc/rfc2954.txt-
../data/rfc/rfc2954.txt- GROUP frnetservAccountPVCGroup
../data/rfc/rfc2954.txt- DESCRIPTION
../data/rfc/rfc2954.txt- "This group is optional for frame relay
../data/rfc/rfc2954.txt- interfaces. It is mandatory if and only if
../data/rfc/rfc2954.txt: accounting is performed on a PVC basis this frame
../data/rfc/rfc2954.txt- relay interface."
../data/rfc/rfc2954.txt- GROUP frnetservAccountLportGroup
../data/rfc/rfc2954.txt- DESCRIPTION
../data/rfc/rfc2954.txt- "This group is optional for frame relay
../data/rfc/rfc2954.txt- interfaces. It is mandatory if and only if
../data/rfc/rfc2954.txt: accounting is performed on a logical port basis
../data/rfc/rfc2954.txt- this frame relay interface."
../data/rfc/rfc2954.txt-
../data/rfc/rfc2954.txt- OBJECT frPVCEndptInMaxFrameSize
../data/rfc/rfc2954.txt-
../data/rfc/rfc2954.txt-
--
../data/rfc/rfc2954.txt-
../data/rfc/rfc2954.txt- GROUP frnetservAccountPVCGroup
../data/rfc/rfc2954.txt- DESCRIPTION
../data/rfc/rfc2954.txt- "This group is optional for frame relay
../data/rfc/rfc2954.txt- interfaces. It is mandatory if and only if
../data/rfc/rfc2954.txt: accounting is performed on a PVC basis this frame
../data/rfc/rfc2954.txt- relay interface."
../data/rfc/rfc2954.txt- GROUP frnetservAccountLportGroup
../data/rfc/rfc2954.txt- DESCRIPTION
../data/rfc/rfc2954.txt- "This group is optional for frame relay
../data/rfc/rfc2954.txt- interfaces. It is mandatory if and only if
../data/rfc/rfc2954.txt: accounting is performed on a logical port basis
../data/rfc/rfc2954.txt- this frame relay interface."
../data/rfc/rfc2954.txt-
../data/rfc/rfc2954.txt- ::= { frnetservCompliances 3 }
../data/rfc/rfc2954.txt-
../data/rfc/rfc2954.txt- --
--
../data/rfc/rfc2954.txt-
../data/rfc/rfc2954.txt- GROUP frnetservAccountPVCGroup
../data/rfc/rfc2954.txt- DESCRIPTION
../data/rfc/rfc2954.txt- "This group is optional for Frame Relay
../data/rfc/rfc2954.txt- interfaces. It is mandatory if and only if
../data/rfc/rfc2954.txt: accounting is performed on a PVC basis this Frame
../data/rfc/rfc2954.txt- Relay interface."
../data/rfc/rfc2954.txt-
../data/rfc/rfc2954.txt- GROUP frnetservAccountLportGroup
../data/rfc/rfc2954.txt- DESCRIPTION
../data/rfc/rfc2954.txt- "This group is optional for Frame Relay
../data/rfc/rfc2954.txt- interfaces. It is mandatory if and only if
../data/rfc/rfc2954.txt: accounting is performed on a logical port basis
../data/rfc/rfc2954.txt- this Frame Relay interface."
../data/rfc/rfc2954.txt-
../data/rfc/rfc2954.txt- OBJECT frPVCEndptInMaxFrameSize
../data/rfc/rfc2954.txt- MIN-ACCESS read-only
../data/rfc/rfc2954.txt- DESCRIPTION
--
../data/rfc/rfc2954.txt- OBJECTS { frAccountPVCSegmentSize,
../data/rfc/rfc2954.txt- frAccountPVCInSegments,
../data/rfc/rfc2954.txt- frAccountPVCOutSegments }
../data/rfc/rfc2954.txt- STATUS current
../data/rfc/rfc2954.txt- DESCRIPTION
../data/rfc/rfc2954.txt: "A collection of objects providing accounting
../data/rfc/rfc2954.txt- information application to a Frame Relay PVC end-
../data/rfc/rfc2954.txt- point."
../data/rfc/rfc2954.txt- ::= { frnetservGroups 5 }
../data/rfc/rfc2954.txt-
../data/rfc/rfc2954.txt- frnetservAccountLportGroup OBJECT-GROUP
../data/rfc/rfc2954.txt- OBJECTS { frAccountLportSegmentSize,
../data/rfc/rfc2954.txt- frAccountLportInSegments,
../data/rfc/rfc2954.txt- frAccountLportOutSegments }
../data/rfc/rfc2954.txt- STATUS current
../data/rfc/rfc2954.txt- DESCRIPTION
../data/rfc/rfc2954.txt: "A collection of objects providing accounting
../data/rfc/rfc2954.txt- information application to a Frame Relay logical
../data/rfc/rfc2954.txt- port."
../data/rfc/rfc2954.txt- ::= { frnetservGroups 6 }
../data/rfc/rfc2954.txt-
../data/rfc/rfc2954.txt- frnetservLportGroup2 OBJECT-GROUP
--
../data/rfc/rfc1604.txt- 4. Object Definitions .................................... 12
../data/rfc/rfc1604.txt- 4.1 The Frame Relay Service Logical Port Group ........... 12
../data/rfc/rfc1604.txt- 4.2 The Frame Relay Management VC Signaling Group ........ 15
../data/rfc/rfc1604.txt- 4.3 The PVC End-Point Group .............................. 22
../data/rfc/rfc1604.txt- 4.4 Frame Relay PVC Connection Group ..................... 30
../data/rfc/rfc1604.txt: 4.5 Frame Relay Accounting Groups ........................ 37
../data/rfc/rfc1604.txt- 5. Frame Relay Network Service TRAPS ..................... 40
../data/rfc/rfc1604.txt- 6. Conformance Information ............................... 43
../data/rfc/rfc1604.txt- 7. Acknowledgments ....................................... 45
../data/rfc/rfc1604.txt- 8. References ............................................ 45
../data/rfc/rfc1604.txt- 9. Security Considerations ............................... 46
--
../data/rfc/rfc1604.txt-Frame Relay Service MIB Working Group [Page 36]
../data/rfc/rfc1604.txt-
../data/rfc/rfc1604.txt-RFC 1604 Frame Relay Service MIB March 1994
../data/rfc/rfc1604.txt-
../data/rfc/rfc1604.txt-
../data/rfc/rfc1604.txt: -- The Frame Relay Accounting Groups
../data/rfc/rfc1604.txt-
../data/rfc/rfc1604.txt- -- The groups are the following:
../data/rfc/rfc1604.txt: -- Accounting on a PVC basis
../data/rfc/rfc1604.txt: -- Accounting on an Interface/Logical Port basis
../data/rfc/rfc1604.txt-
../data/rfc/rfc1604.txt: -- The Accounting on a Frame Relay PVC basis Group
../data/rfc/rfc1604.txt-
../data/rfc/rfc1604.txt: -- The accounting information is collected for a PVC
../data/rfc/rfc1604.txt- -- segment end-point.
../data/rfc/rfc1604.txt-
../data/rfc/rfc1604.txt- frAccountPVCTable OBJECT-TYPE
../data/rfc/rfc1604.txt- SYNTAX SEQUENCE OF FrAccountPVCEntry
../data/rfc/rfc1604.txt- MAX-ACCESS not-accessible
../data/rfc/rfc1604.txt- STATUS current
../data/rfc/rfc1604.txt- DESCRIPTION
../data/rfc/rfc1604.txt: "The Frame Relay Accounting PVC table. This table
../data/rfc/rfc1604.txt: is used to perform accounting on a PVC segment
../data/rfc/rfc1604.txt- end-point basis."
../data/rfc/rfc1604.txt- ::= { frnetservObjects 6 }
../data/rfc/rfc1604.txt-
../data/rfc/rfc1604.txt- frAccountPVCEntry OBJECT-TYPE
../data/rfc/rfc1604.txt- SYNTAX FrAccountPVCEntry
../data/rfc/rfc1604.txt- MAX-ACCESS not-accessible
../data/rfc/rfc1604.txt- STATUS current
../data/rfc/rfc1604.txt- DESCRIPTION
../data/rfc/rfc1604.txt: "An entry in the Frame Relay Accounting PVC
../data/rfc/rfc1604.txt- table."
../data/rfc/rfc1604.txt- INDEX { ifIndex, frAccountPVCDLCIIndex }
../data/rfc/rfc1604.txt- ::= { frAccountPVCTable 1 }
../data/rfc/rfc1604.txt-
../data/rfc/rfc1604.txt- FrAccountPVCEntry ::=
--
../data/rfc/rfc1604.txt- "The value of this object is equal to the number
../data/rfc/rfc1604.txt- of segments sent by this PVC segment end-point."
../data/rfc/rfc1604.txt- ::= { frAccountPVCEntry 4 }
../data/rfc/rfc1604.txt-
../data/rfc/rfc1604.txt-
../data/rfc/rfc1604.txt: -- The Accounting on a Frame Relay Logical Port basis Group
../data/rfc/rfc1604.txt-
../data/rfc/rfc1604.txt-
../data/rfc/rfc1604.txt- frAccountLportTable OBJECT-TYPE
../data/rfc/rfc1604.txt- SYNTAX SEQUENCE OF FrAccountLportEntry
../data/rfc/rfc1604.txt- MAX-ACCESS not-accessible
../data/rfc/rfc1604.txt- STATUS current
../data/rfc/rfc1604.txt- DESCRIPTION
../data/rfc/rfc1604.txt: "The Frame Relay Accounting Logical Port table.
../data/rfc/rfc1604.txt: This table is used to perform accounting on a
../data/rfc/rfc1604.txt- UNI/NNI Logical Port basis."
../data/rfc/rfc1604.txt- ::= { frnetservObjects 7 }
../data/rfc/rfc1604.txt-
../data/rfc/rfc1604.txt- frAccountLportEntry OBJECT-TYPE
../data/rfc/rfc1604.txt-
--
../data/rfc/rfc1604.txt-
../data/rfc/rfc1604.txt- SYNTAX FrAccountLportEntry
../data/rfc/rfc1604.txt- MAX-ACCESS not-accessible
../data/rfc/rfc1604.txt- STATUS current
../data/rfc/rfc1604.txt- DESCRIPTION
../data/rfc/rfc1604.txt: "An entry in the Frame Relay Accounting Logical
../data/rfc/rfc1604.txt- Port table."
../data/rfc/rfc1604.txt- INDEX { ifIndex }
../data/rfc/rfc1604.txt- ::= { frAccountLportTable 1 }
../data/rfc/rfc1604.txt-
../data/rfc/rfc1604.txt- FrAccountLportEntry ::=
--
../data/rfc/rfc1604.txt-
../data/rfc/rfc1604.txt- GROUP frnetservAccountPVCGroup
../data/rfc/rfc1604.txt- DESCRIPTION
../data/rfc/rfc1604.txt- "This group is optional for Frame Relay interfaces.
../data/rfc/rfc1604.txt- It is
../data/rfc/rfc1604.txt: mandatory if and only if accounting is performed
../data/rfc/rfc1604.txt- on a PVC
../data/rfc/rfc1604.txt- basis this
../data/rfc/rfc1604.txt- Frame Relay interface."
../data/rfc/rfc1604.txt-
../data/rfc/rfc1604.txt- GROUP frnetservAccountLportGroup
--
../data/rfc/rfc1604.txt-
../data/rfc/rfc1604.txt-
../data/rfc/rfc1604.txt- DESCRIPTION
../data/rfc/rfc1604.txt- "This group is optional for Frame Relay interfaces.
../data/rfc/rfc1604.txt- It is
../data/rfc/rfc1604.txt: mandatory if and only if accounting is
../data/rfc/rfc1604.txt- performed on a
../data/rfc/rfc1604.txt- logical port basis this
../data/rfc/rfc1604.txt- Frame Relay interface."
../data/rfc/rfc1604.txt-
../data/rfc/rfc1604.txt- OBJECT frPVCEndptInMaxFrameSize
--
../data/rfc/rfc1604.txt- frnetservAccountPVCGroup OBJECT-GROUP
../data/rfc/rfc1604.txt- OBJECTS { frAccountPVCSegmentSize, frAccountPVCInSegments,
../data/rfc/rfc1604.txt- frAccountPVCOutSegments }
../data/rfc/rfc1604.txt- STATUS current
../data/rfc/rfc1604.txt- DESCRIPTION
../data/rfc/rfc1604.txt: "A collection of objects providing accounting
../data/rfc/rfc1604.txt- information application
../data/rfc/rfc1604.txt- to a Frame Relay PVC end-point."
../data/rfc/rfc1604.txt- ::= { frnetservGroups 5 }
../data/rfc/rfc1604.txt-
../data/rfc/rfc1604.txt- frnetservAccountLportGroup OBJECT-GROUP
../data/rfc/rfc1604.txt- OBJECTS { frAccountLportSegmentSize, frAccountLportInSegments,
../data/rfc/rfc1604.txt- frAccountLportOutSegments }
../data/rfc/rfc1604.txt- STATUS current
../data/rfc/rfc1604.txt- DESCRIPTION
../data/rfc/rfc1604.txt: "A collection of objects providing accounting
../data/rfc/rfc1604.txt- information application
../data/rfc/rfc1604.txt- to a Frame Relay logical port."
../data/rfc/rfc1604.txt- ::= { frnetservGroups 6 }
../data/rfc/rfc1604.txt-
../data/rfc/rfc1604.txt-
--
../data/rfc/rfc3162.txt-3. Table of Attributes
../data/rfc/rfc3162.txt-
../data/rfc/rfc3162.txt- The following table provides a guide to which attributes may be found
../data/rfc/rfc3162.txt- in which kinds of packets, and in what quantity.
../data/rfc/rfc3162.txt-
../data/rfc/rfc3162.txt: Request Accept Reject Challenge Accounting # Attribute
../data/rfc/rfc3162.txt- Request
../data/rfc/rfc3162.txt- 0-1 0 0 0 0-1 95 NAS-IPv6-Address
../data/rfc/rfc3162.txt- 0-1 0-1 0 0 0-1 96 Framed-Interface-Id
../data/rfc/rfc3162.txt- 0+ 0+ 0 0 0+ 97 Framed-IPv6-Prefix
../data/rfc/rfc3162.txt- 0+ 0+ 0 0 0+ 98 Login-IPv6-Host
--
../data/rfc/rfc3162.txt-
../data/rfc/rfc3162.txt- [4] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
../data/rfc/rfc3162.txt- Authentication Dial In User Service (RADIUS)", RFC 2865, June
../data/rfc/rfc3162.txt- 2000.
../data/rfc/rfc3162.txt-
../data/rfc/rfc3162.txt: [5] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc3162.txt-
../data/rfc/rfc3162.txt: [6] Zorn, G., Mitton, D. and B. Aboba, "RADIUS Accounting
../data/rfc/rfc3162.txt- Modifications for Tunnel Protocol Support", RFC 2867, June
../data/rfc/rfc3162.txt- 2000.
../data/rfc/rfc3162.txt-
../data/rfc/rfc3162.txt- [7] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M.
../data/rfc/rfc3162.txt- and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support",
--
../data/rfc/rfc3162.txt- Architecture", RFC 2373, July 1998.
../data/rfc/rfc3162.txt-
../data/rfc/rfc3162.txt-5. Security Considerations
../data/rfc/rfc3162.txt-
../data/rfc/rfc3162.txt- This document describes the use of RADIUS for the purposes of
../data/rfc/rfc3162.txt: authentication, authorization and accounting in IPv6-enabled
../data/rfc/rfc3162.txt- networks. In such networks, the RADIUS protocol may run either over
../data/rfc/rfc3162.txt- IPv4 or over IPv6. Known security vulnerabilities of the RADIUS
../data/rfc/rfc3162.txt- protocol are described in [3], [4] and [8].
../data/rfc/rfc3162.txt-
../data/rfc/rfc3162.txt- Since IPSEC [9] is mandatory to implement for IPv6, it is expected
--
../data/rfc/rfc1742.txt- papServerStatus DisplayString,
../data/rfc/rfc1742.txt- papServerCompletedJobs Counter,
../data/rfc/rfc1742.txt- papServerBusyJobs INTEGER,
../data/rfc/rfc1742.txt- papServerFreeJobs INTEGER,
../data/rfc/rfc1742.txt- papServerAuthenticationFailures Counter,
../data/rfc/rfc1742.txt: papServerAccountingFailures Counter,
../data/rfc/rfc1742.txt- papServerGeneralFailures Counter,
../data/rfc/rfc1742.txt- papServerState INTEGER,
../data/rfc/rfc1742.txt- papServerLastStatusMsg DisplayString
../data/rfc/rfc1742.txt- }
../data/rfc/rfc1742.txt-
--
../data/rfc/rfc1742.txt- DESCRIPTION
../data/rfc/rfc1742.txt- "The number of times this PAP server rejected a job
../data/rfc/rfc1742.txt- because the job was not correctly authenticated."
../data/rfc/rfc1742.txt- ::= { papServerEntry 7 }
../data/rfc/rfc1742.txt-
../data/rfc/rfc1742.txt: papServerAccountingFailures OBJECT-TYPE
../data/rfc/rfc1742.txt- SYNTAX Counter
../data/rfc/rfc1742.txt- ACCESS read-only
../data/rfc/rfc1742.txt- STATUS mandatory
../data/rfc/rfc1742.txt- DESCRIPTION
../data/rfc/rfc1742.txt- "The number of times this PAP server rejected a job
../data/rfc/rfc1742.txt: because the job did not fit some accounting rule,
../data/rfc/rfc1742.txt- such as exceeding a quota."
../data/rfc/rfc1742.txt- ::= { papServerEntry 8 }
../data/rfc/rfc1742.txt-
../data/rfc/rfc1742.txt- papServerGeneralFailures OBJECT-TYPE
../data/rfc/rfc1742.txt- SYNTAX Counter
../data/rfc/rfc1742.txt- ACCESS read-only
../data/rfc/rfc1742.txt- STATUS mandatory
../data/rfc/rfc1742.txt- DESCRIPTION
../data/rfc/rfc1742.txt- "The number of times this PAP server rejected a job
../data/rfc/rfc1742.txt- for some reason other than authentication or
../data/rfc/rfc1742.txt: accounting failures."
../data/rfc/rfc1742.txt- ::= { papServerEntry 9 }
../data/rfc/rfc1742.txt-
../data/rfc/rfc1742.txt- papServerState OBJECT-TYPE
../data/rfc/rfc1742.txt- SYNTAX INTEGER {
../data/rfc/rfc1742.txt- valid(1),
--
../data/rfc/rfc5590.txt-RFC 5590 SNMP Transport Subsystem June 2009
../data/rfc/rfc5590.txt-
../data/rfc/rfc5590.txt-
../data/rfc/rfc5590.txt- In times of network stress, a Secure Transport Model might not work
../data/rfc/rfc5590.txt- properly if its underlying security mechanisms (e.g., Network Time
../data/rfc/rfc5590.txt: Protocol (NTP) or Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc5590.txt- protocols or certificate authorities) are not reachable. The User-
../data/rfc/rfc5590.txt- based Security Model was explicitly designed to not depend upon
../data/rfc/rfc5590.txt- external network services, and provides its own security services.
../data/rfc/rfc5590.txt- It is RECOMMENDED that operators provision authPriv USM as a fallback
../data/rfc/rfc5590.txt- mechanism to supplement any Security Model or Transport Model that
--
../data/rfc/rfc5066.txt- active PME (e.g., for 2BaseTL PMEs it is a multiple of 64 Kbps). A
../data/rfc/rfc5066.txt- zero value SHALL be returned when the PME is Initializing or Down.
../data/rfc/rfc5066.txt-
../data/rfc/rfc5066.txt- The ifSpeed of the PCS is the sum of the current operating data rates
../data/rfc/rfc5066.txt- of all PMEs in the aggregation group, without the 64/65-octet
../data/rfc/rfc5066.txt: encapsulation overhead and PAF overhead, but accounting for the
../data/rfc/rfc5066.txt- Inter-Frame Gaps (IFGs).
../data/rfc/rfc5066.txt-
../data/rfc/rfc5066.txt- When using the stated definition of ifSpeed for the PCS, there would
../data/rfc/rfc5066.txt- be no frame loss in the following configuration (the test-sets are
../data/rfc/rfc5066.txt- configured to generate 100% of back-to-back traffic, i.e., minimal
--
../data/rfc/rfc5066.txt- | | 2BASE-TL PME, vdsl(97) for 10PASS-TS PME. |
../data/rfc/rfc5066.txt- | ifSpeed | Operating data rate for the PME. For the PCS, it |
../data/rfc/rfc5066.txt- | | is the sum of the current operating data rates of |
../data/rfc/rfc5066.txt- | | all PMEs in the aggregation group, without the |
../data/rfc/rfc5066.txt- | | 64/65-octet encapsulation overhead and PAF |
../data/rfc/rfc5066.txt: | | overhead, but accounting for the Inter-Frame Gaps |
../data/rfc/rfc5066.txt- | | (IFGs). |
../data/rfc/rfc5066.txt- +---------------+---------------------------------------------------+
../data/rfc/rfc5066.txt- | ifAdminStatus | Setting this object to 'up' instructs a |
../data/rfc/rfc5066.txt- | | particular PCS (with all PMEs connected to it) or |
../data/rfc/rfc5066.txt- | | PME to start initialization process. |
--
../data/rfc/rfc2621.txt-Request for Comments: 2621 B. Aboba
../data/rfc/rfc2621.txt-Category: Informational Microsoft
../data/rfc/rfc2621.txt- June 1999
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt: RADIUS Accounting Server MIB
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-Status of this Memo
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt- This memo provides information for the Internet community. This memo
../data/rfc/rfc2621.txt- does not specify an Internet standard of any kind. Distribution of
--
../data/rfc/rfc2621.txt- Copyright (C) The Internet Society (1999). All Rights Reserved.
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-Abstract
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt- This memo defines a set of extensions which instrument RADIUS
../data/rfc/rfc2621.txt: accounting server functions. These extensions represent a portion of
../data/rfc/rfc2621.txt- the Management Information Base (MIB) for use with network management
../data/rfc/rfc2621.txt- protocols in the Internet community. Using these extensions IP-based
../data/rfc/rfc2621.txt: management stations can manage RADIUS accounting servers.
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-1. Introduction
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt- This memo defines a portion of the Management Information Base (MIB)
../data/rfc/rfc2621.txt- for use with network management protocols in the Internet community.
../data/rfc/rfc2621.txt- In particular, it describes managed objects used for managing RADIUS
../data/rfc/rfc2621.txt: accounting servers.
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt: RADIUS accounting servers are today widely deployed by dialup
../data/rfc/rfc2621.txt: Internet Service Providers, in order to provide accounting services.
../data/rfc/rfc2621.txt: As a result, the effective management of RADIUS accounting servers is
../data/rfc/rfc2621.txt- of considerable importance.
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-2. The SNMP Management Framework
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt- The SNMP Management Framework presently consists of five major
--
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-Zorn & Aboba Informational [Page 1]
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt:RFC 2621 RADIUS Accounting Server MIB June 1999
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt- STD 15, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4].
../data/rfc/rfc2621.txt- The second version, called SMIv2, is described in STD 58, RFC
../data/rfc/rfc2621.txt- 2578 [5], RFC 2579 [6] and RFC 2580 [7].
--
../data/rfc/rfc2621.txt- readable information is not considered to change the semantics of the
../data/rfc/rfc2621.txt- MIB.
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-3. Overview
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt: The RADIUS accounting protocol, described in [16], distinguishes
../data/rfc/rfc2621.txt- between the client function and the server function. In RADIUS
../data/rfc/rfc2621.txt: accounting, clients send Accounting-Requests, and servers reply with
../data/rfc/rfc2621.txt: Accounting-Responses. Typically NAS devices implement the client
../data/rfc/rfc2621.txt- function, and thus would be expected to implement the RADIUS
../data/rfc/rfc2621.txt: accounting client MIB, while RADIUS accounting servers implement the
../data/rfc/rfc2621.txt- server function, and thus would be expected to implement the RADIUS
../data/rfc/rfc2621.txt: accounting server MIB.
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-Zorn & Aboba Informational [Page 2]
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt:RFC 2621 RADIUS Accounting Server MIB June 1999
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt: However, it is possible for a RADIUS accounting entity to perform
../data/rfc/rfc2621.txt- both client and server functions. For example, a RADIUS proxy may act
../data/rfc/rfc2621.txt: as a server to one or more RADIUS accounting clients, while
../data/rfc/rfc2621.txt: simultaneously acting as an accounting client to one or more
../data/rfc/rfc2621.txt: accounting servers. In such situations, it is expected that RADIUS
../data/rfc/rfc2621.txt- entities combining client and server functionality will support both
../data/rfc/rfc2621.txt- the client and server MIBs.
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-3.1. Selected objects
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt- This MIB module contains thirteen scalars as well as a single table:
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt: (1) the RADIUS Accounting Client Table contains one row for each
../data/rfc/rfc2621.txt: RADIUS accounting client that the server shares a secret with.
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt: Each entry in the RADIUS Accounting Client Table includes eleven
../data/rfc/rfc2621.txt: columns presenting a view of the activity of the RADIUS accounting
../data/rfc/rfc2621.txt- server.
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-4. Definitions
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-RADIUS-ACC-SERVER-MIB DEFINITIONS ::= BEGIN
--
../data/rfc/rfc2621.txt- Phone: +1 425 936 6605
../data/rfc/rfc2621.txt- EMail: bernarda@microsoft.com"
../data/rfc/rfc2621.txt- DESCRIPTION
../data/rfc/rfc2621.txt- "The MIB module for entities implementing the server
../data/rfc/rfc2621.txt- side of the Remote Access Dialin User Service (RADIUS)
../data/rfc/rfc2621.txt: accounting protocol."
../data/rfc/rfc2621.txt- REVISION "9906110000Z" -- 11 Jun 1999
../data/rfc/rfc2621.txt- DESCRIPTION "Initial version as published in RFC 2621"
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-Zorn & Aboba Informational [Page 3]
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt:RFC 2621 RADIUS Accounting Server MIB June 1999
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt: ::= { radiusAccounting 1 }
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-radiusMIB OBJECT-IDENTITY
../data/rfc/rfc2621.txt- STATUS current
../data/rfc/rfc2621.txt- DESCRIPTION
../data/rfc/rfc2621.txt- "The OID assigned to RADIUS MIB work by the IANA."
../data/rfc/rfc2621.txt- ::= { mib-2 67 }
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt:radiusAccounting OBJECT IDENTIFIER ::= {radiusMIB 2}
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-radiusAccServMIBObjects OBJECT IDENTIFIER ::=
../data/rfc/rfc2621.txt- { radiusAccServMIB 1 }
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-radiusAccServ OBJECT IDENTIFIER ::= { radiusAccServMIBObjects 1 }
--
../data/rfc/rfc2621.txt- SYNTAX SnmpAdminString
../data/rfc/rfc2621.txt- MAX-ACCESS read-only
../data/rfc/rfc2621.txt- STATUS current
../data/rfc/rfc2621.txt- DESCRIPTION
../data/rfc/rfc2621.txt- "The implementation identification string for the
../data/rfc/rfc2621.txt: RADIUS accounting server software in use on the
../data/rfc/rfc2621.txt- system, for example; `FNS-2.1'"
../data/rfc/rfc2621.txt- ::= {radiusAccServ 1}
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-radiusAccServUpTime OBJECT-TYPE
../data/rfc/rfc2621.txt- SYNTAX TimeTicks
--
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-Zorn & Aboba Informational [Page 4]
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt:RFC 2621 RADIUS Accounting Server MIB June 1999
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt- this value will be zero."
../data/rfc/rfc2621.txt- ::= {radiusAccServ 3}
../data/rfc/rfc2621.txt-
--
../data/rfc/rfc2621.txt- SYNTAX Counter32
../data/rfc/rfc2621.txt- MAX-ACCESS read-only
../data/rfc/rfc2621.txt- STATUS current
../data/rfc/rfc2621.txt- DESCRIPTION
../data/rfc/rfc2621.txt- "The number of packets received on the
../data/rfc/rfc2621.txt: accounting port."
../data/rfc/rfc2621.txt- ::= { radiusAccServ 5 }
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-radiusAccServTotalInvalidRequests OBJECT-TYPE
../data/rfc/rfc2621.txt- SYNTAX Counter32
../data/rfc/rfc2621.txt- MAX-ACCESS read-only
../data/rfc/rfc2621.txt- STATUS current
../data/rfc/rfc2621.txt- DESCRIPTION
../data/rfc/rfc2621.txt: "The number of RADIUS Accounting-Request packets
../data/rfc/rfc2621.txt- received from unknown addresses."
../data/rfc/rfc2621.txt- ::= { radiusAccServ 6 }
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-radiusAccServTotalDupRequests OBJECT-TYPE
../data/rfc/rfc2621.txt- SYNTAX Counter32
../data/rfc/rfc2621.txt- MAX-ACCESS read-only
../data/rfc/rfc2621.txt- STATUS current
../data/rfc/rfc2621.txt- DESCRIPTION
../data/rfc/rfc2621.txt: "The number of duplicate RADIUS Accounting-Request
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-Zorn & Aboba Informational [Page 5]
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt:RFC 2621 RADIUS Accounting Server MIB June 1999
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt- packets received."
../data/rfc/rfc2621.txt- ::= { radiusAccServ 7 }
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-radiusAccServTotalResponses OBJECT-TYPE
../data/rfc/rfc2621.txt- SYNTAX Counter32
../data/rfc/rfc2621.txt- MAX-ACCESS read-only
../data/rfc/rfc2621.txt- STATUS current
../data/rfc/rfc2621.txt- DESCRIPTION
../data/rfc/rfc2621.txt: "The number of RADIUS Accounting-Response packets sent."
../data/rfc/rfc2621.txt- ::= { radiusAccServ 8 }
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-radiusAccServTotalMalformedRequests OBJECT-TYPE
../data/rfc/rfc2621.txt- SYNTAX Counter32
../data/rfc/rfc2621.txt- MAX-ACCESS read-only
../data/rfc/rfc2621.txt- STATUS current
../data/rfc/rfc2621.txt- DESCRIPTION
../data/rfc/rfc2621.txt: "The number of malformed RADIUS Accounting-Request
../data/rfc/rfc2621.txt- packets received. Bad authenticators or unknown
../data/rfc/rfc2621.txt- types are not included as malformed Access-Requests."
../data/rfc/rfc2621.txt- ::= { radiusAccServ 9 }
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-radiusAccServTotalBadAuthenticators OBJECT-TYPE
../data/rfc/rfc2621.txt- SYNTAX Counter32
../data/rfc/rfc2621.txt- MAX-ACCESS read-only
../data/rfc/rfc2621.txt- STATUS current
../data/rfc/rfc2621.txt- DESCRIPTION
../data/rfc/rfc2621.txt: "The number of RADIUS Accounting-Request packets
../data/rfc/rfc2621.txt- which contained invalid Signature attributes."
../data/rfc/rfc2621.txt- ::= { radiusAccServ 10 }
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-radiusAccServTotalPacketsDropped OBJECT-TYPE
../data/rfc/rfc2621.txt- SYNTAX Counter32
--
../data/rfc/rfc2621.txt-radiusAccServTotalNoRecords OBJECT-TYPE
../data/rfc/rfc2621.txt- SYNTAX Counter32
../data/rfc/rfc2621.txt- MAX-ACCESS read-only
../data/rfc/rfc2621.txt- STATUS current
../data/rfc/rfc2621.txt- DESCRIPTION
../data/rfc/rfc2621.txt: "The number of RADIUS Accounting-Request packets
../data/rfc/rfc2621.txt- which were received and responded to but not
../data/rfc/rfc2621.txt- recorded."
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-Zorn & Aboba Informational [Page 6]
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt:RFC 2621 RADIUS Accounting Server MIB June 1999
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt- ::= { radiusAccServ 12 }
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-radiusAccServTotalUnknownTypes OBJECT-TYPE
--
../data/rfc/rfc2621.txt-radiusAccClientTable OBJECT-TYPE
../data/rfc/rfc2621.txt- SYNTAX SEQUENCE OF RadiusAccClientEntry
../data/rfc/rfc2621.txt- MAX-ACCESS not-accessible
../data/rfc/rfc2621.txt- STATUS current
../data/rfc/rfc2621.txt- DESCRIPTION
../data/rfc/rfc2621.txt: "The (conceptual) table listing the RADIUS accounting
../data/rfc/rfc2621.txt- clients with which the server shares a secret."
../data/rfc/rfc2621.txt- ::= { radiusAccServ 14 }
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-radiusAccClientEntry OBJECT-TYPE
../data/rfc/rfc2621.txt- SYNTAX RadiusAccClientEntry
../data/rfc/rfc2621.txt- MAX-ACCESS not-accessible
../data/rfc/rfc2621.txt- STATUS current
../data/rfc/rfc2621.txt- DESCRIPTION
../data/rfc/rfc2621.txt- "An entry (conceptual row) representing a RADIUS
../data/rfc/rfc2621.txt: accounting client with which the server shares a secret."
../data/rfc/rfc2621.txt- INDEX { radiusAccClientIndex }
../data/rfc/rfc2621.txt- ::= { radiusAccClientTable 1 }
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-RadiusAccClientEntry ::= SEQUENCE {
../data/rfc/rfc2621.txt- radiusAccClientIndex Integer32,
--
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-Zorn & Aboba Informational [Page 7]
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt:RFC 2621 RADIUS Accounting Server MIB June 1999
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt- MAX-ACCESS not-accessible
../data/rfc/rfc2621.txt- STATUS current
../data/rfc/rfc2621.txt- DESCRIPTION
../data/rfc/rfc2621.txt: "A number uniquely identifying each RADIUS accounting
../data/rfc/rfc2621.txt- client with which this server communicates."
../data/rfc/rfc2621.txt- ::= { radiusAccClientEntry 1 }
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-radiusAccClientAddress OBJECT-TYPE
../data/rfc/rfc2621.txt- SYNTAX IpAddress
../data/rfc/rfc2621.txt- MAX-ACCESS read-only
../data/rfc/rfc2621.txt- STATUS current
../data/rfc/rfc2621.txt- DESCRIPTION
../data/rfc/rfc2621.txt: "The NAS-IP-Address of the RADIUS accounting client
../data/rfc/rfc2621.txt- referred to in this table entry."
../data/rfc/rfc2621.txt- ::= { radiusAccClientEntry 2 }
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-radiusAccClientID OBJECT-TYPE
../data/rfc/rfc2621.txt- SYNTAX SnmpAdminString
../data/rfc/rfc2621.txt- MAX-ACCESS read-only
../data/rfc/rfc2621.txt- STATUS current
../data/rfc/rfc2621.txt- DESCRIPTION
../data/rfc/rfc2621.txt: "The NAS-Identifier of the RADIUS accounting client
../data/rfc/rfc2621.txt- referred to in this table entry. This is not necessarily
../data/rfc/rfc2621.txt- the same as sysName in MIB II."
../data/rfc/rfc2621.txt- ::= { radiusAccClientEntry 3 }
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt--- Server Counters
--
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-Zorn & Aboba Informational [Page 8]
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt:RFC 2621 RADIUS Accounting Server MIB June 1999
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt- STATUS current
../data/rfc/rfc2621.txt- DESCRIPTION
../data/rfc/rfc2621.txt- "The number of packets received from this
../data/rfc/rfc2621.txt: client on the accounting port."
../data/rfc/rfc2621.txt- ::= { radiusAccClientEntry 5 }
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-radiusAccServDupRequests OBJECT-TYPE
../data/rfc/rfc2621.txt- SYNTAX Counter32
../data/rfc/rfc2621.txt- MAX-ACCESS read-only
../data/rfc/rfc2621.txt- STATUS current
../data/rfc/rfc2621.txt- DESCRIPTION
../data/rfc/rfc2621.txt: "The number of duplicate RADIUS Accounting-Request
../data/rfc/rfc2621.txt- packets received from this client."
../data/rfc/rfc2621.txt- ::= { radiusAccClientEntry 6 }
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-radiusAccServResponses OBJECT-TYPE
../data/rfc/rfc2621.txt- SYNTAX Counter32
../data/rfc/rfc2621.txt- MAX-ACCESS read-only
../data/rfc/rfc2621.txt- STATUS current
../data/rfc/rfc2621.txt- DESCRIPTION
../data/rfc/rfc2621.txt: "The number of RADIUS Accounting-Response packets
../data/rfc/rfc2621.txt- sent to this client."
../data/rfc/rfc2621.txt- ::= { radiusAccClientEntry 7 }
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-radiusAccServBadAuthenticators OBJECT-TYPE
../data/rfc/rfc2621.txt- SYNTAX Counter32
../data/rfc/rfc2621.txt- MAX-ACCESS read-only
../data/rfc/rfc2621.txt- STATUS current
../data/rfc/rfc2621.txt- DESCRIPTION
../data/rfc/rfc2621.txt: "The number of RADIUS Accounting-Request packets
../data/rfc/rfc2621.txt- which contained invalid authenticators received
../data/rfc/rfc2621.txt- from this client."
../data/rfc/rfc2621.txt- ::= { radiusAccClientEntry 8 }
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-radiusAccServMalformedRequests OBJECT-TYPE
../data/rfc/rfc2621.txt- SYNTAX Counter32
../data/rfc/rfc2621.txt- MAX-ACCESS read-only
../data/rfc/rfc2621.txt- STATUS current
../data/rfc/rfc2621.txt- DESCRIPTION
../data/rfc/rfc2621.txt: "The number of malformed RADIUS Accounting-Request
../data/rfc/rfc2621.txt- packets which were received from this client.
../data/rfc/rfc2621.txt- Bad authenticators and unknown types
../data/rfc/rfc2621.txt: are not included as malformed Accounting-Requests."
../data/rfc/rfc2621.txt- ::= { radiusAccClientEntry 9 }
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-radiusAccServNoRecords OBJECT-TYPE
../data/rfc/rfc2621.txt- SYNTAX Counter32
../data/rfc/rfc2621.txt- MAX-ACCESS read-only
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-Zorn & Aboba Informational [Page 9]
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt:RFC 2621 RADIUS Accounting Server MIB June 1999
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt- STATUS current
../data/rfc/rfc2621.txt- DESCRIPTION
../data/rfc/rfc2621.txt: "The number of RADIUS Accounting-Request packets
../data/rfc/rfc2621.txt- which were received and responded to but not
../data/rfc/rfc2621.txt- recorded."
../data/rfc/rfc2621.txt- ::= { radiusAccClientEntry 10 }
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-radiusAccServUnknownTypes OBJECT-TYPE
--
../data/rfc/rfc2621.txt--- compliance statements
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-radiusAccServMIBCompliance MODULE-COMPLIANCE
../data/rfc/rfc2621.txt- STATUS current
../data/rfc/rfc2621.txt- DESCRIPTION
../data/rfc/rfc2621.txt: "The compliance statement for accounting servers
../data/rfc/rfc2621.txt: implementing the RADIUS Accounting Server MIB."
../data/rfc/rfc2621.txt- MODULE -- this module
../data/rfc/rfc2621.txt- MANDATORY-GROUPS { radiusAccServMIBGroup }
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt- OBJECT radiusAccServConfigReset
../data/rfc/rfc2621.txt- WRITE-SYNTAX INTEGER { reset(2) }
--
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-Zorn & Aboba Informational [Page 10]
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt:RFC 2621 RADIUS Accounting Server MIB June 1999
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt- radiusAccServResetTime,
../data/rfc/rfc2621.txt- radiusAccServConfigReset,
../data/rfc/rfc2621.txt- radiusAccServTotalRequests,
--
../data/rfc/rfc2621.txt- radiusAccServUnknownTypes
../data/rfc/rfc2621.txt- }
../data/rfc/rfc2621.txt- STATUS current
../data/rfc/rfc2621.txt- DESCRIPTION
../data/rfc/rfc2621.txt- "The collection of objects providing management of
../data/rfc/rfc2621.txt: a RADIUS Accounting Server."
../data/rfc/rfc2621.txt- ::= { radiusAccServMIBGroups 1 }
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-END
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-5. References
--
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-Zorn & Aboba Informational [Page 11]
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt:RFC 2621 RADIUS Accounting Server MIB June 1999
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt- [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
../data/rfc/rfc2621.txt- M. and S. Waldbusser, "Structure of Management Information
../data/rfc/rfc2621.txt- Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
--
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt- [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access
../data/rfc/rfc2621.txt- Control Model for the Simple Network Management Protocol
../data/rfc/rfc2621.txt- (SNMP)", RFC 2575, April 1999.
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt: [16] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-Zorn & Aboba Informational [Page 12]
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt:RFC 2621 RADIUS Accounting Server MIB June 1999
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-6. Security Considerations
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt- There are management objects (radiusAccServConfigReset) defined in
--
../data/rfc/rfc2621.txt- There are a number of managed objects in this MIB that may contain
../data/rfc/rfc2621.txt- sensitive information. These are:
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt- radiusAccClientAddress
../data/rfc/rfc2621.txt- This can be used to determine the address of the RADIUS
../data/rfc/rfc2621.txt: accounting client with which the server is communicating.
../data/rfc/rfc2621.txt- This information could be useful in impersonating the
../data/rfc/rfc2621.txt- client.
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt- radiusAccClientID This can be used to determine the client ID for the
../data/rfc/rfc2621.txt: accounting client with which the server is communicating.
../data/rfc/rfc2621.txt- This information could be useful in impersonating the
../data/rfc/rfc2621.txt- client.
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt- It is thus important to control even GET access to these objects and
../data/rfc/rfc2621.txt- possibly to even encrypt the values of these object when sending them
--
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-Zorn & Aboba Informational [Page 13]
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt:RFC 2621 RADIUS Accounting Server MIB June 1999
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-8. Authors' Addresses
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt- Bernard Aboba
--
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-Zorn & Aboba Informational [Page 14]
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt:RFC 2621 RADIUS Accounting Server MIB June 1999
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt-9. Full Copyright Statement
../data/rfc/rfc2621.txt-
../data/rfc/rfc2621.txt- Copyright (C) The Internet Society (1999). All Rights Reserved.
--
../data/rfc/rfc5433.txt- discard the packet.
../data/rfc/rfc5433.txt-
../data/rfc/rfc5433.txt- GPSK-1 contains no MAC protection, so provided it properly parses, it
../data/rfc/rfc5433.txt- MUST be accepted by the peer. If the EAP peer has no ciphersuites in
../data/rfc/rfc5433.txt- common with the server or decides the ID_Server is that of an
../data/rfc/rfc5433.txt: Authentication, Authorization, and Accounting (AAA) server to which
../data/rfc/rfc5433.txt- it does not wish to authenticate, the EAP peer MUST respond with an
../data/rfc/rfc5433.txt- EAP-NAK.
../data/rfc/rfc5433.txt-
../data/rfc/rfc5433.txt- For GPSK-2, if the ID_Peer is for an unknown user, the EAP server
../data/rfc/rfc5433.txt- MUST send either a "PSK Not Found" GPSK-Fail message or an
--
../data/rfc/rfc7944.txt-
../data/rfc/rfc7944.txt-11.1. AVP Codes
../data/rfc/rfc7944.txt-
../data/rfc/rfc7944.txt- The new AVP defined by this specification is listed in Section 9.
../data/rfc/rfc7944.txt- All AVP codes are allocated from the "AVP Codes" subregistry of the
../data/rfc/rfc7944.txt: "Authentication, Authorization, and Accounting (AAA) Parameters"
../data/rfc/rfc7944.txt- registry.
../data/rfc/rfc7944.txt-
../data/rfc/rfc7944.txt-12. Security Considerations
../data/rfc/rfc7944.txt-
../data/rfc/rfc7944.txt- DRMP gives Diameter nodes the ability to influence which requests are
--
../data/rfc/rfc2594.txt- Application MIB [24].
../data/rfc/rfc2594.txt-
../data/rfc/rfc2594.txt- This document defines a set of managed objects to monitor WWW
../data/rfc/rfc2594.txt- services for short-term operational purposes, such as problem
../data/rfc/rfc2594.txt- detection and troubleshooting. No attempts are made here to cover
../data/rfc/rfc2594.txt: accounting or hit metering issues.
../data/rfc/rfc2594.txt-
../data/rfc/rfc2594.txt- The scope of the MIB is further limited by the requirement that an
../data/rfc/rfc2594.txt- implementation conforming to this MIB must be possible without
../data/rfc/rfc2594.txt- putting a huge CPU or memory burden on the WWW server implementation.
../data/rfc/rfc2594.txt-
--
../data/rfc/rfc5664.txt- When parity is present in the file, then there is an additional
../data/rfc/rfc5664.txt- computation to map from the file offset L to the offset that accounts
../data/rfc/rfc5664.txt- for embedded parity, L'. First compute L', and then use L' in the
../data/rfc/rfc5664.txt- above equations for C and O.
../data/rfc/rfc5664.txt-
../data/rfc/rfc5664.txt: L = file offset, not accounting for parity
../data/rfc/rfc5664.txt- P = number of parity devices in each stripe
../data/rfc/rfc5664.txt- W = group_width, if not zero, else size of olo_components array
../data/rfc/rfc5664.txt- N = L / (W-P * stripe_unit)
../data/rfc/rfc5664.txt- L' = N * (W * stripe_unit) +
../data/rfc/rfc5664.txt- (L % (W-P * stripe_unit))
--
../data/rfc/rfc5664.txt- get C'. Finally, increase C' by one if the parity information comes
../data/rfc/rfc5664.txt- at or before C' within that stripe. The following equations
../data/rfc/rfc5664.txt- illustrate this by computing I, which is the index of the component
../data/rfc/rfc5664.txt- that contains parity for a given stripe.
../data/rfc/rfc5664.txt-
../data/rfc/rfc5664.txt: L = file offset, not accounting for parity
../data/rfc/rfc5664.txt- W = odm_group_width, if not zero, else size of olo_components array
../data/rfc/rfc5664.txt- N = L / (W-1 * stripe_unit)
../data/rfc/rfc5664.txt- (Compute L' as describe above)
../data/rfc/rfc5664.txt- (Compute C based on L' as described above)
../data/rfc/rfc5664.txt- C' = (C - (N%W)) % W
--
../data/rfc/rfc3837.txt- 2.2.9. Denial of Service (DoS) . . . . . . . . . . . . 9
../data/rfc/rfc3837.txt- 2.2.10. Tracing and Notification Information . . . . . . 9
../data/rfc/rfc3837.txt- 2.2.11. Unauthenticated Communication in OPES Flow . . . 9
../data/rfc/rfc3837.txt- 3. Threats to Out-of-Band Data . . . . . . . . . . . . . . . . . 9
../data/rfc/rfc3837.txt- 3.1. Threats that Endanger the OPES Data Flow . . . . . . . . 10
../data/rfc/rfc3837.txt: 3.2. Inaccurate Accounting Information . . . . . . . . . . . 10
../data/rfc/rfc3837.txt- 3.3. OPES Service Request Repudiation . . . . . . . . . . . . 11
../data/rfc/rfc3837.txt- 3.4. Inconsistent Privacy Policy . . . . . . . . . . . . . . 11
../data/rfc/rfc3837.txt- 3.5. Exposure of Privacy Preferences . . . . . . . . . . . . 11
../data/rfc/rfc3837.txt- 3.6. Exposure of Security Settings . . . . . . . . . . . . . 11
../data/rfc/rfc3837.txt- 3.7. Improper Enforcement of Privacy and Security Policy . . 11
--
../data/rfc/rfc3837.txt-
../data/rfc/rfc3837.txt- An OPES system implementation should address all these threats and
../data/rfc/rfc3837.txt- prove its robustness and ability to withstand malicious attacks or
../data/rfc/rfc3837.txt- networking and programming problems.
../data/rfc/rfc3837.txt-
../data/rfc/rfc3837.txt:3.2. Inaccurate Accounting Information
../data/rfc/rfc3837.txt-
../data/rfc/rfc3837.txt: Collecting and reporting accurate accounting data may be vital when
../data/rfc/rfc3837.txt- OPES servers are used to extend a business model of a content
../data/rfc/rfc3837.txt- provider, service provider, or as a basis for third party service.
../data/rfc/rfc3837.txt: The ability to collect and process accounting data is an important
../data/rfc/rfc3837.txt- part of OPES' system functionality. This functionality may be
../data/rfc/rfc3837.txt: challenged by distortion or destruction of base accounting data
../data/rfc/rfc3837.txt: (usually logs), processed accounting data, accounting parameters, and
../data/rfc/rfc3837.txt- reporting configuration.
../data/rfc/rfc3837.txt-
../data/rfc/rfc3837.txt- As a result a data consumer may be inappropriately charged for
../data/rfc/rfc3837.txt- viewing content that was not successfully delivered, or a content
../data/rfc/rfc3837.txt- provider or independent OPES services provider may not be compensated
../data/rfc/rfc3837.txt- for the services performed.
../data/rfc/rfc3837.txt-
../data/rfc/rfc3837.txt: The OPES system may use accounting information to distribute
../data/rfc/rfc3837.txt- resources between different consumers or limit resource usage by a
../data/rfc/rfc3837.txt: specific consumer. In this case an attack on the accounting system
../data/rfc/rfc3837.txt- (by distortion of data or issuing false configuration commands) may
../data/rfc/rfc3837.txt- result in incorrect resource management and DoS by artificial
../data/rfc/rfc3837.txt- resource starvation.
../data/rfc/rfc3837.txt-
../data/rfc/rfc3837.txt-
--
../data/rfc/rfc1946.txt-
../data/rfc/rfc1946.txt- The requested maximum byte transmission rate for ST-2 is:
../data/rfc/rfc1946.txt-
../data/rfc/rfc1946.txt- PDUbytes * PDUrate * 10.
../data/rfc/rfc1946.txt-
../data/rfc/rfc1946.txt: Accounting for the AAL 5 and ST headers, the maximum byte rate
../data/rfc/rfc1946.txt- is:
../data/rfc/rfc1946.txt-
../data/rfc/rfc1946.txt- Bytes per second = (PDUbytes + 8 + 8) * PDUrate * 10.
../data/rfc/rfc1946.txt-
../data/rfc/rfc1946.txt- Translating into cells and eliminating the possibility of a
--
../data/rfc/rfc8565.txt- A generic solution to this problem is to use an "Anti-HTJP-Nonce"
../data/rfc/rfc8565.txt- HTTP header in HTTP responses. The value of an "Anti-HTJP-Nonce"
../data/rfc/rfc8565.txt- header SHOULD be a cryptographically secure random number in any
../data/rfc/rfc8565.txt- encoding that is valid for an HTTP header value. The length of this
../data/rfc/rfc8565.txt- number SHOULD be determined by the producer of the HTTP response,
../data/rfc/rfc8565.txt: accounting for their method of random number generation and their
../data/rfc/rfc8565.txt- threat model.
../data/rfc/rfc8565.txt-
../data/rfc/rfc8565.txt-7.2. HTJPS
../data/rfc/rfc8565.txt-
../data/rfc/rfc8565.txt- HTJP, being just HTTP, has most of the same security concerns and
--
../data/rfc/rfc5475.txt- counts [JePP92] up to the estimation of whole distributions of flow
../data/rfc/rfc5475.txt- characteristics (e.g., packet sizes) [ClPB93].
../data/rfc/rfc5475.txt-
../data/rfc/rfc5475.txt- Second, the required accuracy of the information and with this, the
../data/rfc/rfc5475.txt- confidence that is aimed at, should be known in advance. For
../data/rfc/rfc5475.txt: instance, for usage-based accounting the required confidence for the
../data/rfc/rfc5475.txt- estimation of packet counters can depend on the monetary value that
../data/rfc/rfc5475.txt- corresponds to the transfer of one packet. That means that a higher
../data/rfc/rfc5475.txt- confidence could be required for expensive packet flows (e.g.,
../data/rfc/rfc5475.txt- premium IP service) than for cheaper flows (e.g., best effort). The
../data/rfc/rfc5475.txt- accuracy requirements for validating a previously agreed quality can
--
../data/rfc/rfc5475.txt- [DuLT01] N.G. Duffield, C. Lund, and M. Thorup, "Charging from
../data/rfc/rfc5475.txt- Sampled Network Usage", ACM Internet Measurement Workshop
../data/rfc/rfc5475.txt- IMW 2001, San Francisco, USA, November 1-2, 2001.
../data/rfc/rfc5475.txt-
../data/rfc/rfc5475.txt- [EsVa01] C. Estan and G. Varghese, "New Directions in Traffic
../data/rfc/rfc5475.txt: Measurement and Accounting", ACM SIGCOMM Internet
../data/rfc/rfc5475.txt- Measurement Workshop 2001, San Francisco (CA) Nov. 2001.
../data/rfc/rfc5475.txt-
../data/rfc/rfc5475.txt- [GoRe07] S. Goldberg, J. Rexford, "Security Vulnerabilities and
../data/rfc/rfc5475.txt- Solutions for Packet Sampling", IEEE Sarnoff Symposium,
../data/rfc/rfc5475.txt- Princeton, NJ, May 2007.
--
../data/rfc/rfc1107.txt-
../data/rfc/rfc1107.txt- - Accountability:
../data/rfc/rfc1107.txt-
../data/rfc/rfc1107.txt- Accountability is important both for allocation and recovery of
../data/rfc/rfc1107.txt- costs. Vendors may provide commercial directory services,
../data/rfc/rfc1107.txt: therefore depending on accounting as part of their successful
../data/rfc/rfc1107.txt- commercial ventures.
../data/rfc/rfc1107.txt-
../data/rfc/rfc1107.txt- - Multiple Interfaces:
../data/rfc/rfc1107.txt-
../data/rfc/rfc1107.txt- There should be both human and programming interfaces to the
--
../data/rfc/rfc4441.txt-
../data/rfc/rfc4441.txt-Abstract
../data/rfc/rfc4441.txt-
../data/rfc/rfc4441.txt- Since the late 1980s, IEEE 802 and IETF have cooperated in the
../data/rfc/rfc4441.txt- development of Simple Network Management Protocol (SNMP) MIBs and
../data/rfc/rfc4441.txt: Authentication, Authorization, and Accounting (AAA) applications.
../data/rfc/rfc4441.txt- This document describes the policies and procedures that have
../data/rfc/rfc4441.txt- developed in order to coordinate between the two organizations, as
../data/rfc/rfc4441.txt- well as some of the relationship history.
../data/rfc/rfc4441.txt-
../data/rfc/rfc4441.txt-Table of Contents
--
../data/rfc/rfc4441.txt-
../data/rfc/rfc4441.txt-1. Introduction
../data/rfc/rfc4441.txt-
../data/rfc/rfc4441.txt- Since the late 1980s, participants in IEEE 802 and the IETF have
../data/rfc/rfc4441.txt- cooperated in the development of Management Information Bases (MIBs)
../data/rfc/rfc4441.txt: and Authentication, Authorization, and Accounting (AAA) applications
../data/rfc/rfc4441.txt- relating to IEEE standards. This has included the Bridge MIB
../data/rfc/rfc4441.txt- [RFC1493] [RFC4188], the multicast filtering and VLAN extension MIB
../data/rfc/rfc4441.txt- [RFC2674] [RFC4363], the Hub MIB [RFC2108], the Ethernet-like
../data/rfc/rfc4441.txt- Interfaces MIB [RFC3635], the MAU MIB [RFC3636], the WAN Interfaces
../data/rfc/rfc4441.txt- Sublayer MIB [RFC3637], the Power Ethernet MIB [RFC3621], IEEE 802.1X
--
../data/rfc/rfc4441.txt-
../data/rfc/rfc4441.txt- [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
../data/rfc/rfc4441.txt- "Remote Authentication Dial In User Service
../data/rfc/rfc4441.txt- (RADIUS)", RFC 2865, June 2000.
../data/rfc/rfc4441.txt-
../data/rfc/rfc4441.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc4441.txt-
../data/rfc/rfc4441.txt- [RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS
../data/rfc/rfc4441.txt: Accounting Modifications for Tunnel Protocol
../data/rfc/rfc4441.txt- Support", RFC 2867, June 2000.
../data/rfc/rfc4441.txt-
../data/rfc/rfc4441.txt- [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J.,
../data/rfc/rfc4441.txt- Holdrege, M., and I. Goyret, "RADIUS Attributes for
../data/rfc/rfc4441.txt- Tunnel Protocol Support", RFC 2868, June 2000.
--
../data/rfc/rfc3588.txt- Copyright (C) The Internet Society (2003). All Rights Reserved.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-Abstract
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- The Diameter base protocol is intended to provide an Authentication,
../data/rfc/rfc3588.txt: Authorization and Accounting (AAA) framework for applications such as
../data/rfc/rfc3588.txt- network access or IP mobility. Diameter is also intended to work in
../data/rfc/rfc3588.txt: both local Authentication, Authorization & Accounting and roaming
../data/rfc/rfc3588.txt- situations. This document specifies the message format, transport,
../data/rfc/rfc3588.txt: error reporting, accounting and security services to be used by all
../data/rfc/rfc3588.txt- Diameter applications. The Diameter base application needs to be
../data/rfc/rfc3588.txt- supported by all Diameter implementations.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-Conventions Used In This Document
../data/rfc/rfc3588.txt-
--
../data/rfc/rfc3588.txt- 1.1.1. Description of the Document Set.............. 10
../data/rfc/rfc3588.txt- 1.2. Approach to Extensibility............................. 11
../data/rfc/rfc3588.txt- 1.2.1. Defining New AVP Values...................... 11
../data/rfc/rfc3588.txt- 1.2.2. Creating New AVPs............................ 11
../data/rfc/rfc3588.txt- 1.2.3. Creating New Authentication Applications..... 11
../data/rfc/rfc3588.txt: 1.2.4. Creating New Accounting Applications......... 12
../data/rfc/rfc3588.txt- 1.2.5. Application Authentication Procedures........ 14
../data/rfc/rfc3588.txt- 1.3. Terminology........................................... 14
../data/rfc/rfc3588.txt- 2. Protocol Overview............................................ 18
../data/rfc/rfc3588.txt- 2.1. Transport............................................. 20
../data/rfc/rfc3588.txt- 2.1.1. SCTP Guidelines.............................. 21
--
../data/rfc/rfc3588.txt- 7.5. Failed-AVP AVP........................................ 89
../data/rfc/rfc3588.txt- 7.6. Experimental-Result AVP............................... 90
../data/rfc/rfc3588.txt- 7.7. Experimental-Result-Code AVP.......................... 90
../data/rfc/rfc3588.txt- 8. Diameter User Sessions....................................... 90
../data/rfc/rfc3588.txt- 8.1. Authorization Session State Machine................... 92
../data/rfc/rfc3588.txt: 8.2. Accounting Session State Machine...................... 96
../data/rfc/rfc3588.txt- 8.3. Server-Initiated Re-Auth.............................. 101
../data/rfc/rfc3588.txt- 8.3.1. Re-Auth-Request.............................. 102
../data/rfc/rfc3588.txt- 8.3.2. Re-Auth-Answer............................... 102
../data/rfc/rfc3588.txt- 8.4. Session Termination................................... 103
../data/rfc/rfc3588.txt- 8.4.1. Session-Termination-Request.................. 104
--
../data/rfc/rfc3588.txt- 8.17. Session-Binding AVP................................... 113
../data/rfc/rfc3588.txt- 8.18. Session-Server-Failover AVP........................... 113
../data/rfc/rfc3588.txt- 8.19. Multi-Round-Time-Out AVP.............................. 114
../data/rfc/rfc3588.txt- 8.20. Class AVP............................................. 114
../data/rfc/rfc3588.txt- 8.21. Event-Timestamp AVP................................... 115
../data/rfc/rfc3588.txt: 9. Accounting................................................... 115
../data/rfc/rfc3588.txt- 9.1. Server Directed Model................................. 115
../data/rfc/rfc3588.txt- 9.2. Protocol Messages..................................... 116
../data/rfc/rfc3588.txt- 9.3. Application Document Requirements..................... 116
../data/rfc/rfc3588.txt- 9.4. Fault Resilience...................................... 116
../data/rfc/rfc3588.txt: 9.5. Accounting Records.................................... 117
../data/rfc/rfc3588.txt: 9.6. Correlation of Accounting Records..................... 118
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-Calhoun, et al. Standards Track [Page 4]
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-RFC 3588 Diameter Based Protocol September 2003
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: 9.7. Accounting Command-Codes.............................. 119
../data/rfc/rfc3588.txt: 9.7.1. Accounting-Request........................... 119
../data/rfc/rfc3588.txt: 9.7.2. Accounting-Answer............................ 120
../data/rfc/rfc3588.txt: 9.8. Accounting AVPs....................................... 121
../data/rfc/rfc3588.txt: 9.8.1. Accounting-Record-Type AVP................... 121
../data/rfc/rfc3588.txt- 9.8.2. Acct-Interim-Interval AVP.................... 122
../data/rfc/rfc3588.txt: 9.8.3. Accounting-Record-Number AVP................. 123
../data/rfc/rfc3588.txt- 9.8.4. Acct-Session-Id AVP.......................... 123
../data/rfc/rfc3588.txt- 9.8.5. Acct-Multi-Session-Id AVP.................... 123
../data/rfc/rfc3588.txt: 9.8.6. Accounting-Sub-Session-Id AVP................ 123
../data/rfc/rfc3588.txt: 9.8.7. Accounting-Realtime-Required AVP............. 123
../data/rfc/rfc3588.txt- 10. AVP Occurrence Table......................................... 124
../data/rfc/rfc3588.txt- 10.1. Base Protocol Command AVP Table....................... 124
../data/rfc/rfc3588.txt: 10.2. Accounting AVP Table.................................. 126
../data/rfc/rfc3588.txt- 11. IANA Considerations.......................................... 127
../data/rfc/rfc3588.txt- 11.1. AVP Header............................................ 127
../data/rfc/rfc3588.txt- 11.1.1. AVP Code..................................... 127
../data/rfc/rfc3588.txt- 11.1.2. AVP Flags.................................... 128
../data/rfc/rfc3588.txt- 11.2. Diameter Header....................................... 128
../data/rfc/rfc3588.txt- 11.2.1. Command Codes................................ 128
../data/rfc/rfc3588.txt- 11.2.2. Command Flags................................ 129
../data/rfc/rfc3588.txt- 11.3. Application Identifiers............................... 129
../data/rfc/rfc3588.txt- 11.4. AVP Values............................................ 129
../data/rfc/rfc3588.txt- 11.4.1. Result-Code AVP Values....................... 129
../data/rfc/rfc3588.txt: 11.4.2. Accounting-Record-Type AVP Values............ 130
../data/rfc/rfc3588.txt- 11.4.3. Termination-Cause AVP Values................. 130
../data/rfc/rfc3588.txt- 11.4.4. Redirect-Host-Usage AVP Values............... 130
../data/rfc/rfc3588.txt- 11.4.5. Session-Server-Failover AVP Values........... 130
../data/rfc/rfc3588.txt- 11.4.6. Session-Binding AVP Values................... 130
../data/rfc/rfc3588.txt- 11.4.7. Disconnect-Cause AVP Values.................. 130
../data/rfc/rfc3588.txt- 11.4.8. Auth-Request-Type AVP Values................. 130
../data/rfc/rfc3588.txt- 11.4.9. Auth-Session-State AVP Values................ 130
../data/rfc/rfc3588.txt- 11.4.10. Re-Auth-Request-Type AVP Values.............. 131
../data/rfc/rfc3588.txt: 11.4.11. Accounting-Realtime-Required AVP Values...... 131
../data/rfc/rfc3588.txt- 11.5. Diameter TCP/SCTP Port Numbers........................ 131
../data/rfc/rfc3588.txt- 11.6. NAPTR Service Fields.................................. 131
../data/rfc/rfc3588.txt- 12. Diameter Protocol Related Configurable Parameters............ 131
../data/rfc/rfc3588.txt- 13. Security Considerations...................................... 132
../data/rfc/rfc3588.txt- 13.1. IPsec Usage........................................... 133
--
../data/rfc/rfc3588.txt- Authors' Addresses............................................... 146
../data/rfc/rfc3588.txt- Full Copyright Statement......................................... 147
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-1. Introduction
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: Authentication, Authorization and Accounting (AAA) protocols such as
../data/rfc/rfc3588.txt- TACACS [TACACS] and RADIUS [RADIUS] were initially deployed to
../data/rfc/rfc3588.txt- provide dial-up PPP [PPP] and terminal server access. Over time,
../data/rfc/rfc3588.txt- with the growth of the Internet and the introduction of new access
../data/rfc/rfc3588.txt- technologies, including wireless, DSL, Mobile IP and Ethernet,
../data/rfc/rfc3588.txt- routers and network access servers (NAS) have increased in complexity
--
../data/rfc/rfc3588.txt- scheme that is required only for use with Response packets. While
../data/rfc/rfc3588.txt- [RADEXT] defines an additional authentication and integrity
../data/rfc/rfc3588.txt- mechanism, use is only required during Extensible Authentication
../data/rfc/rfc3588.txt- Protocol (EAP) sessions. While attribute-hiding is supported,
../data/rfc/rfc3588.txt- [RADIUS] does not provide support for per-packet confidentiality.
../data/rfc/rfc3588.txt: In accounting, [RADACCT] assumes that replay protection is
../data/rfc/rfc3588.txt- provided by the backend billing server, rather than within the
../data/rfc/rfc3588.txt- protocol itself.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- While [RFC3162] defines the use of IPsec with RADIUS, support for
../data/rfc/rfc3588.txt- IPsec is not required. Since within [IKE] authentication occurs
--
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Reliable transport
../data/rfc/rfc3588.txt- RADIUS runs over UDP, and does not define retransmission behavior;
../data/rfc/rfc3588.txt- as a result, reliability varies between implementations. As
../data/rfc/rfc3588.txt: described in [ACCMGMT], this is a major issue in accounting, where
../data/rfc/rfc3588.txt- packet loss may translate directly into revenue loss. In order to
../data/rfc/rfc3588.txt- provide well defined transport behavior, Diameter runs over
../data/rfc/rfc3588.txt- reliable transport mechanisms (TCP, SCTP) as defined in
../data/rfc/rfc3588.txt- [AAATRANS].
../data/rfc/rfc3588.txt-
--
../data/rfc/rfc3588.txt- - Capabilities negotiation
../data/rfc/rfc3588.txt- - Error notification
../data/rfc/rfc3588.txt- - Extensibility, through addition of new commands and AVPs (required
../data/rfc/rfc3588.txt- in [AAAREQ]).
../data/rfc/rfc3588.txt- - Basic services necessary for applications, such as handling of
../data/rfc/rfc3588.txt: user sessions or accounting
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- All data delivered by the protocol is in the form of an AVP. Some of
../data/rfc/rfc3588.txt- these AVP values are used by the Diameter protocol itself, while
../data/rfc/rfc3588.txt- others deliver data associated with particular applications that
../data/rfc/rfc3588.txt- employ Diameter. AVPs may be added arbitrarily to Diameter messages,
--
../data/rfc/rfc3588.txt- - Transporting of service specific authorization information,
../data/rfc/rfc3588.txt- between client and servers, allowing the peers to decide whether a
../data/rfc/rfc3588.txt- user's access request should be granted.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- - Exchanging resource usage information, which MAY be used for
../data/rfc/rfc3588.txt: accounting purposes, capacity planning, etc.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- - Relaying, proxying and redirecting of Diameter messages through a
../data/rfc/rfc3588.txt- server hierarchy.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- The Diameter base protocol provides the minimum requirements needed
../data/rfc/rfc3588.txt- for a AAA protocol, as required by [AAAREQ]. The base protocol may
../data/rfc/rfc3588.txt: be used by itself for accounting purposes only, or it may be used
../data/rfc/rfc3588.txt- with a Diameter application, such as Mobile IPv4 [DIAMMIP], or
../data/rfc/rfc3588.txt- network access [NASREQ]. It is also possible for the base protocol
../data/rfc/rfc3588.txt- to be extended for use in new applications, via the addition of new
../data/rfc/rfc3588.txt- commands or AVPs. At this time the focus of Diameter is network
../data/rfc/rfc3588.txt: access and accounting applications. A truly generic AAA protocol
../data/rfc/rfc3588.txt- used by many applications might provide functionality not provided by
../data/rfc/rfc3588.txt- Diameter. Therefore, it is imperative that the designers of new
../data/rfc/rfc3588.txt- applications understand their requirements before using Diameter.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
--
../data/rfc/rfc3588.txt- Any node can initiate a request. In that sense, Diameter is a peer-
../data/rfc/rfc3588.txt- to-peer protocol. In this document, a Diameter Client is a device at
../data/rfc/rfc3588.txt- the edge of the network that performs access control, such as a
../data/rfc/rfc3588.txt- Network Access Server (NAS) or a Foreign Agent (FA). A Diameter
../data/rfc/rfc3588.txt- client generates Diameter messages to request authentication,
../data/rfc/rfc3588.txt: authorization, and accounting services for the user. A Diameter
../data/rfc/rfc3588.txt- agent is a node that does not authenticate and/or authorize messages
../data/rfc/rfc3588.txt- locally; agents include proxies, redirects and relay agents. A
../data/rfc/rfc3588.txt- Diameter server performs authentication and/or authorization of the
../data/rfc/rfc3588.txt- user. A Diameter node MAY act as an agent for certain requests while
../data/rfc/rfc3588.txt- acting as a server for others.
--
../data/rfc/rfc3588.txt- Terminal Server Access environment. Consideration was given for
../data/rfc/rfc3588.txt- servers that need to perform protocol conversion between Diameter and
../data/rfc/rfc3588.txt- RADIUS.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- In summary, this document defines the base protocol specification for
../data/rfc/rfc3588.txt: AAA, which includes support for accounting. The Mobile IPv4 and the
../data/rfc/rfc3588.txt- NASREQ documents describe applications that use this base
../data/rfc/rfc3588.txt: specification for Authentication, Authorization and Accounting.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
--
../data/rfc/rfc3588.txt- mechanisms, including:
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- - Defining new AVP values
../data/rfc/rfc3588.txt- - Creating new AVPs
../data/rfc/rfc3588.txt- - Creating new authentication/authorization applications
../data/rfc/rfc3588.txt: - Creating new accounting applications
../data/rfc/rfc3588.txt- - Application authentication procedures
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Reuse of existing AVP values, AVPs and Diameter applications are
../data/rfc/rfc3588.txt- strongly recommended. Reuse simplifies standardization and
../data/rfc/rfc3588.txt- implementation and avoids potential interoperability issues. It is
--
../data/rfc/rfc3588.txt- In order to justify allocation of a new application identifier,
../data/rfc/rfc3588.txt- Diameter applications MUST define one Command Code, or add new
../data/rfc/rfc3588.txt- mandatory AVPs to the ABNF.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- The expected AVPs MUST be defined in an ABNF [ABNF] grammar (see
../data/rfc/rfc3588.txt: Section 3.2). If the Diameter application has accounting
../data/rfc/rfc3588.txt- requirements, it MUST also specify the AVPs that are to be present in
../data/rfc/rfc3588.txt: the Diameter Accounting messages (see Section 9.3). However, just
../data/rfc/rfc3588.txt- because a new authentication application id is required, does not
../data/rfc/rfc3588.txt: imply that a new accounting application id is required.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- When possible, a new Diameter application SHOULD reuse existing
../data/rfc/rfc3588.txt- Diameter AVPs, in order to avoid defining multiple AVPs that carry
../data/rfc/rfc3588.txt- similar information.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt:1.2.4. Creating New Accounting Applications
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: There are services that only require Diameter accounting. Such
../data/rfc/rfc3588.txt: services need to define the AVPs carried in the Accounting-Request
../data/rfc/rfc3588.txt: (ACR)/ Accounting-Answer (ACA) messages, but do not need to define
../data/rfc/rfc3588.txt- new command codes. An implementation MAY add arbitrary non-mandatory
../data/rfc/rfc3588.txt- AVPs (AVPs with the "M" bit not set) to any command defined in an
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
--
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-RFC 3588 Diameter Based Protocol September 2003
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- application, including vendor-specific AVPs, without needing to
../data/rfc/rfc3588.txt: define a new accounting application. Please refer to Section 11.1.1
../data/rfc/rfc3588.txt- for details.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Application Identifiers are still required for Diameter capability
../data/rfc/rfc3588.txt: exchange. Every Diameter accounting application specification MUST
../data/rfc/rfc3588.txt- have an IANA assigned Application Identifier (see Section 2.4) or a
../data/rfc/rfc3588.txt- vendor specific Application Identifier.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: Every Diameter implementation MUST support accounting. Basic
../data/rfc/rfc3588.txt: accounting support is sufficient to handle any application that uses
../data/rfc/rfc3588.txt- the ACR/ACA commands defined in this document, as long as no new
../data/rfc/rfc3588.txt- mandatory AVPs are added. A mandatory AVP is defined as one which
../data/rfc/rfc3588.txt: has the "M" bit set when sent within an accounting command,
../data/rfc/rfc3588.txt- regardless of whether it is required or optional within the ABNF for
../data/rfc/rfc3588.txt: the accounting application.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: The creation of a new accounting application should be viewed as a
../data/rfc/rfc3588.txt- last resort and MUST NOT be used unless a new command or additional
../data/rfc/rfc3588.txt- mechanisms (e.g., application defined state machine) is defined
../data/rfc/rfc3588.txt- within the application, or new mandatory AVPs are added to the ABNF.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: Within an accounting command, setting the "M" bit implies that a
../data/rfc/rfc3588.txt: backend server (e.g., billing server) or the accounting server itself
../data/rfc/rfc3588.txt- MUST understand the AVP in order to compute a correct bill. If the
../data/rfc/rfc3588.txt- AVP is not relevant to the billing process, when the AVP is included
../data/rfc/rfc3588.txt: within an accounting command, it MUST NOT have the "M" bit set, even
../data/rfc/rfc3588.txt- if the "M" bit is set when the same AVP is used within other Diameter
../data/rfc/rfc3588.txt- commands (i.e., authentication/authorization commands).
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: A DIAMETER base accounting implementation MUST be configurable to
../data/rfc/rfc3588.txt: advertise supported accounting applications in order to prevent the
../data/rfc/rfc3588.txt: accounting server from accepting accounting requests for unbillable
../data/rfc/rfc3588.txt: services. The combination of the home domain and the accounting
../data/rfc/rfc3588.txt- application Id can be used in order to route the request to the
../data/rfc/rfc3588.txt: appropriate accounting server.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: When possible, a new Diameter accounting application SHOULD attempt
../data/rfc/rfc3588.txt- to reuse existing AVPs, in order to avoid defining multiple AVPs that
../data/rfc/rfc3588.txt- carry similar information.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: If the base accounting is used without any mandatory AVPs, new
../data/rfc/rfc3588.txt- commands or additional mechanisms (e.g., application defined state
../data/rfc/rfc3588.txt: machine), then the base protocol defined standard accounting
../data/rfc/rfc3588.txt- application Id (Section 2.4) MUST be used in ACR/ACA commands.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
--
../data/rfc/rfc3588.txt- such as Extensible Authentication Protocol [EAP], SHOULD be used.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-1.3. Terminology
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- AAA
../data/rfc/rfc3588.txt: Authentication, Authorization and Accounting.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: Accounting
../data/rfc/rfc3588.txt- The act of collecting information on resource usage for the
../data/rfc/rfc3588.txt- purpose of capacity planning, auditing, billing or cost
../data/rfc/rfc3588.txt- allocation.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: Accounting Record
../data/rfc/rfc3588.txt: An accounting record represents a summary of the resource
../data/rfc/rfc3588.txt: consumption of a user over the entire session. Accounting servers
../data/rfc/rfc3588.txt: creating the accounting record may do so by processing interim
../data/rfc/rfc3588.txt: accounting events or accounting events from several devices
../data/rfc/rfc3588.txt- serving the same user.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Authentication
../data/rfc/rfc3588.txt- The act of verifying the identity of an entity (subject).
../data/rfc/rfc3588.txt-
--
../data/rfc/rfc3588.txt- AVP
../data/rfc/rfc3588.txt- The Diameter protocol consists of a header followed by one or more
../data/rfc/rfc3588.txt- Attribute-Value-Pairs (AVPs). An AVP includes a header and is
../data/rfc/rfc3588.txt- used to encapsulate protocol-specific data (e.g., routing
../data/rfc/rfc3588.txt- information) as well as authentication, authorization or
../data/rfc/rfc3588.txt: accounting information.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Broker
../data/rfc/rfc3588.txt- A broker is a business term commonly used in AAA infrastructures.
../data/rfc/rfc3588.txt- A broker is either a relay, proxy or redirect agent, and MAY be
../data/rfc/rfc3588.txt- operated by roaming consortiums. Depending on the business model,
--
../data/rfc/rfc3588.txt- A Diameter Security Exchange is a process through which two
../data/rfc/rfc3588.txt- Diameter nodes establish end-to-end security.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Diameter Server
../data/rfc/rfc3588.txt- A Diameter Server is one that handles authentication,
../data/rfc/rfc3588.txt: authorization and accounting requests for a particular realm. By
../data/rfc/rfc3588.txt- its very nature, a Diameter Server MUST support Diameter
../data/rfc/rfc3588.txt- applications in addition to the base protocol.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Downstream
../data/rfc/rfc3588.txt- Downstream is used to identify the direction of a particular
--
../data/rfc/rfc3588.txt-Calhoun, et al. Standards Track [Page 15]
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-RFC 3588 Diameter Based Protocol September 2003
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: Interim accounting
../data/rfc/rfc3588.txt: An interim accounting message provides a snapshot of usage during
../data/rfc/rfc3588.txt- a user's session. It is typically implemented in order to provide
../data/rfc/rfc3588.txt: for partial accounting of a user's session in the case of a device
../data/rfc/rfc3588.txt- reboot or other network problem prevents the reception of a
../data/rfc/rfc3588.txt- session summary message or session record.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Local Realm
../data/rfc/rfc3588.txt- A local realm is the administrative domain providing services to a
--
../data/rfc/rfc3588.txt-Calhoun, et al. Standards Track [Page 16]
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-RFC 3588 Diameter Based Protocol September 2003
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: Real-time Accounting
../data/rfc/rfc3588.txt: Real-time accounting involves the processing of information on
../data/rfc/rfc3588.txt- resource usage within a defined time window. Time constraints are
../data/rfc/rfc3588.txt- typically imposed in order to limit financial risk.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Relay Agent or Relay
../data/rfc/rfc3588.txt- Relays forward requests and responses based on routing-related
--
../data/rfc/rfc3588.txt- Sub-session
../data/rfc/rfc3588.txt- A sub-session represents a distinct service (e.g., QoS or data
../data/rfc/rfc3588.txt- characteristics) provided to a given session. These services may
../data/rfc/rfc3588.txt- happen concurrently (e.g., simultaneous voice and data transfer
../data/rfc/rfc3588.txt- during the same session) or serially. These changes in sessions
../data/rfc/rfc3588.txt: are tracked with the Accounting-Sub-Session-Id.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Transaction state
../data/rfc/rfc3588.txt- The Diameter protocol requires that agents maintain transaction
../data/rfc/rfc3588.txt- state, which is used for failover purposes. Transaction state
../data/rfc/rfc3588.txt- implies that upon forwarding a request, the Hop-by-Hop identifier
--
../data/rfc/rfc3588.txt- The entity requesting or using some resource, in support of which
../data/rfc/rfc3588.txt- a Diameter client has generated a request.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-2. Protocol Overview
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: The base Diameter protocol may be used by itself for accounting
../data/rfc/rfc3588.txt- applications, but for use in authentication and authorization it is
../data/rfc/rfc3588.txt- always extended for a particular application. Two Diameter
../data/rfc/rfc3588.txt- applications are defined by companion documents: NASREQ [NASREQ],
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
--
../data/rfc/rfc3588.txt- Mobile IPv4 [DIAMMIP]. These applications are introduced in this
../data/rfc/rfc3588.txt- document but specified elsewhere. Additional Diameter applications
../data/rfc/rfc3588.txt- MAY be defined in the future (see Section 11.3).
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Diameter Clients MUST support the base protocol, which includes
../data/rfc/rfc3588.txt: accounting. In addition, they MUST fully support each Diameter
../data/rfc/rfc3588.txt- application that is needed to implement the client's service, e.g.,
../data/rfc/rfc3588.txt- NASREQ and/or Mobile IPv4. A Diameter Client that does not support
../data/rfc/rfc3588.txt- both NASREQ and Mobile IPv4, MUST be referred to as "Diameter X
../data/rfc/rfc3588.txt- Client" where X is the application which it supports, and not a
../data/rfc/rfc3588.txt- "Diameter Client".
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Diameter Servers MUST support the base protocol, which includes
../data/rfc/rfc3588.txt: accounting. In addition, they MUST fully support each Diameter
../data/rfc/rfc3588.txt- application that is needed to implement the intended service, e.g.,
../data/rfc/rfc3588.txt- NASREQ and/or Mobile IPv4. A Diameter Server that does not support
../data/rfc/rfc3588.txt- both NASREQ and Mobile IPv4, MUST be referred to as "Diameter X
../data/rfc/rfc3588.txt- Server" where X is the application which it supports, and not a
../data/rfc/rfc3588.txt- "Diameter Server".
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Diameter Relays and redirect agents are, by definition, protocol
../data/rfc/rfc3588.txt- transparent, and MUST transparently support the Diameter base
../data/rfc/rfc3588.txt: protocol, which includes accounting, and all Diameter applications.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Diameter proxies MUST support the base protocol, which includes
../data/rfc/rfc3588.txt: accounting. In addition, they MUST fully support each Diameter
../data/rfc/rfc3588.txt- application that is needed to implement proxied services, e.g.,
../data/rfc/rfc3588.txt- NASREQ and/or Mobile IPv4. A Diameter proxy which does not support
../data/rfc/rfc3588.txt- also both NASREQ and Mobile IPv4, MUST be referred to as "Diameter X
../data/rfc/rfc3588.txt- Proxy" where X is the application which it supports, and not a
../data/rfc/rfc3588.txt- "Diameter Proxy".
--
../data/rfc/rfc3588.txt- The following Application Identifier values are defined:
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Diameter Common Messages 0
../data/rfc/rfc3588.txt- NASREQ 1 [NASREQ]
../data/rfc/rfc3588.txt- Mobile-IP 2 [DIAMMIP]
../data/rfc/rfc3588.txt: Diameter Base Accounting 3
../data/rfc/rfc3588.txt- Relay 0xffffffff
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Relay and redirect agents MUST advertise the Relay Application
../data/rfc/rfc3588.txt- Identifier, while all other Diameter nodes MUST advertise locally
../data/rfc/rfc3588.txt- supported applications. The receiver of a Capabilities Exchange
--
../data/rfc/rfc3588.txt- - Never use end-to-end security.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- - Use end-to-end security on messages containing sensitive AVPs.
../data/rfc/rfc3588.txt- Which AVPs are sensitive is determined by service provider policy.
../data/rfc/rfc3588.txt- AVPs containing keys and passwords should be considered sensitive.
../data/rfc/rfc3588.txt: Accounting AVPs may be considered sensitive. Any AVP for which
../data/rfc/rfc3588.txt- the P bit may be set or which may be encrypted may be considered
../data/rfc/rfc3588.txt- sensitive.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- - Always use end-to-end security.
../data/rfc/rfc3588.txt-
--
../data/rfc/rfc3588.txt- transaction as specified by the contractual relationship between the
../data/rfc/rfc3588.txt- server and the previous hop. A DIAMETER_AUTHORIZATION_REJECTED error
../data/rfc/rfc3588.txt- message (see Section 7.1.5) is sent if the route traversed by the
../data/rfc/rfc3588.txt- request is unacceptable.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: A home realm may also wish to check that each accounting request
../data/rfc/rfc3588.txt- message corresponds to a Diameter response authorizing the session.
../data/rfc/rfc3588.txt: Accounting requests without corresponding authorization responses
../data/rfc/rfc3588.txt: SHOULD be subjected to further scrutiny, as should accounting
../data/rfc/rfc3588.txt- requests indicating a difference between the requested and provided
../data/rfc/rfc3588.txt- service.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Similarly, the local Diameter agent, on receiving a Diameter response
../data/rfc/rfc3588.txt- authorizing a session, MUST check the Route-Record AVPs to make sure
--
../data/rfc/rfc3588.txt- step, forwarding of an authorization response is considered evidence
../data/rfc/rfc3588.txt- of a willingness to take on financial risk relative to the session.
../data/rfc/rfc3588.txt- A local realm may wish to limit this exposure, for example, by
../data/rfc/rfc3588.txt- establishing credit limits for intermediate realms and refusing to
../data/rfc/rfc3588.txt- accept responses which would violate those limits. By issuing an
../data/rfc/rfc3588.txt: accounting request corresponding to the authorization response, the
../data/rfc/rfc3588.txt- local realm implicitly indicates its agreement to provide the service
../data/rfc/rfc3588.txt- indicated in the authorization response. If the service cannot be
../data/rfc/rfc3588.txt- provided by the local realm, then a DIAMETER_UNABLE_TO_COMPLY error
../data/rfc/rfc3588.txt: message MUST be sent within the accounting request; a Diameter client
../data/rfc/rfc3588.txt- receiving an authorization response for a service that it cannot
../data/rfc/rfc3588.txt- perform MUST NOT substitute an alternate service, and then send
../data/rfc/rfc3588.txt: accounting requests for the alternate service instead.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
--
../data/rfc/rfc3588.txt- 11.3).
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Application-ID
../data/rfc/rfc3588.txt- Application-ID is four octets and is used to identify to which
../data/rfc/rfc3588.txt- application the message is applicable for. The application can be
../data/rfc/rfc3588.txt: an authentication application, an accounting application or a
../data/rfc/rfc3588.txt- vendor specific application. See Section 11.3 for the possible
../data/rfc/rfc3588.txt- values that the application-id may use.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- The application-id in the header MUST be the same as what is
../data/rfc/rfc3588.txt- contained in any relevant AVPs contained in the message.
--
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Command-Name Abbrev. Code Reference
../data/rfc/rfc3588.txt- --------------------------------------------------------
../data/rfc/rfc3588.txt- Abort-Session-Request ASR 274 8.5.1
../data/rfc/rfc3588.txt- Abort-Session-Answer ASA 274 8.5.2
../data/rfc/rfc3588.txt: Accounting-Request ACR 271 9.7.1
../data/rfc/rfc3588.txt: Accounting-Answer ACA 271 9.7.2
../data/rfc/rfc3588.txt- Capabilities-Exchange- CER 257 5.3.1
../data/rfc/rfc3588.txt- Request
../data/rfc/rfc3588.txt- Capabilities-Exchange- CEA 257 5.3.2
../data/rfc/rfc3588.txt- Answer
../data/rfc/rfc3588.txt- Device-Watchdog-Request DWR 280 5.5.1
--
../data/rfc/rfc3588.txt- Additional information, encoded within AVPs, MAY also be included in
../data/rfc/rfc3588.txt- answer messages.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-4. Diameter AVPs
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: Diameter AVPs carry specific authentication, accounting,
../data/rfc/rfc3588.txt- authorization, routing and security information as well as
../data/rfc/rfc3588.txt- configuration details for the request and reply.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Some AVPs MAY be listed more than once. The effect of such an AVP is
../data/rfc/rfc3588.txt- specific, and is specified in each case by the AVP description.
--
../data/rfc/rfc3588.txt- AVP Section | | |SHLD| MUST| |
../data/rfc/rfc3588.txt- Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr|
../data/rfc/rfc3588.txt- -----------------------------------------|----+-----+----+-----|----|
../data/rfc/rfc3588.txt- Acct- 85 9.8.2 Unsigned32 | M | P | | V | Y |
../data/rfc/rfc3588.txt- Interim-Interval | | | | | |
../data/rfc/rfc3588.txt: Accounting- 483 9.8.7 Enumerated | M | P | | V | Y |
../data/rfc/rfc3588.txt- Realtime-Required | | | | | |
../data/rfc/rfc3588.txt- Acct- 50 9.8.5 UTF8String | M | P | | V | Y |
../data/rfc/rfc3588.txt- Multi-Session-Id | | | | | |
../data/rfc/rfc3588.txt: Accounting- 485 9.8.3 Unsigned32 | M | P | | V | Y |
../data/rfc/rfc3588.txt- Record-Number | | | | | |
../data/rfc/rfc3588.txt: Accounting- 480 9.8.1 Enumerated | M | P | | V | Y |
../data/rfc/rfc3588.txt- Record-Type | | | | | |
../data/rfc/rfc3588.txt: Accounting- 44 9.8.4 OctetString| M | P | | V | Y |
../data/rfc/rfc3588.txt- Session-Id | | | | | |
../data/rfc/rfc3588.txt: Accounting- 287 9.8.6 Unsigned64 | M | P | | V | Y |
../data/rfc/rfc3588.txt- Sub-Session-Id | | | | | |
../data/rfc/rfc3588.txt- Acct- 259 6.9 Unsigned32 | M | P | | V | N |
../data/rfc/rfc3588.txt- Application-Id | | | | | |
../data/rfc/rfc3588.txt- Auth- 258 6.8 Unsigned32 | M | P | | V | N |
../data/rfc/rfc3588.txt- Application-Id | | | | | |
--
../data/rfc/rfc3588.txt- specification and have an Application ID assigned.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-6.9. Acct-Application-Id AVP
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- The Acct-Application-Id AVP (AVP Code 259) is of type Unsigned32 and
../data/rfc/rfc3588.txt: is used in order to advertise support of the Accounting portion of an
../data/rfc/rfc3588.txt- application (see Section 2.4). The Acct-Application-Id MUST also be
../data/rfc/rfc3588.txt: present in all Accounting messages. Exactly one of the Auth-
../data/rfc/rfc3588.txt- Application-Id and Acct-Application-Id AVPs MAY be present.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-6.10. Inband-Security-Id AVP
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- The Inband-Security-Id AVP (AVP Code 299) is of type Unsigned32 and
--
../data/rfc/rfc3588.txt- The authentication process for the user failed, most likely due to
../data/rfc/rfc3588.txt- an invalid password used by the user. Further attempts MUST only
../data/rfc/rfc3588.txt- be tried after prompting the user for a new password.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- DIAMETER_OUT_OF_SPACE 4002
../data/rfc/rfc3588.txt: A Diameter node received the accounting request but was unable to
../data/rfc/rfc3588.txt- commit it to stable storage due to a temporary lack of space.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- ELECTION_LOST 4003
../data/rfc/rfc3588.txt- The peer has determined that it has lost the election process and
../data/rfc/rfc3588.txt- has therefore disconnected the transport connection.
--
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-8. Diameter User Sessions
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Diameter can provide two different types of services to applications.
../data/rfc/rfc3588.txt- The first involves authentication and authorization, and can
../data/rfc/rfc3588.txt: optionally make use of accounting. The second only makes use of
../data/rfc/rfc3588.txt: accounting.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-Calhoun, et al. Standards Track [Page 90]
--
../data/rfc/rfc3588.txt- When a service makes use of the authentication and/or authorization
../data/rfc/rfc3588.txt- portion of an application, and a user requests access to the network,
../data/rfc/rfc3588.txt- the Diameter client issues an auth request to its local server. The
../data/rfc/rfc3588.txt- auth request is defined in a service specific Diameter application
../data/rfc/rfc3588.txt- (e.g., NASREQ). The request contains a Session-Id AVP, which is used
../data/rfc/rfc3588.txt: in subsequent messages (e.g., subsequent authorization, accounting,
../data/rfc/rfc3588.txt- etc) relating to the user's session. The Session-Id AVP is a means
../data/rfc/rfc3588.txt- for the client and servers to correlate a Diameter message with a
../data/rfc/rfc3588.txt- user session.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- When a Diameter server authorizes a user to use network resources for
--
../data/rfc/rfc3588.txt-Calhoun, et al. Standards Track [Page 91]
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-RFC 3588 Diameter Based Protocol September 2003
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: When a service only makes use of the Accounting portion of the
../data/rfc/rfc3588.txt- Diameter protocol, even in combination with an application, the
../data/rfc/rfc3588.txt- Session-Id is still used to identify user sessions. However, the
../data/rfc/rfc3588.txt- session termination messages are not used, since a session is
../data/rfc/rfc3588.txt: signaled as being terminated by issuing an accounting stop message.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-8.1. Authorization Session State Machine
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- This section contains a set of finite state machines, representing
../data/rfc/rfc3588.txt- the life cycle of Diameter sessions, and which MUST be observed by
--
../data/rfc/rfc3588.txt- -------------------------------------------------------------
../data/rfc/rfc3588.txt- Idle Service-specific authorization Send serv. Idle
../data/rfc/rfc3588.txt- request received, and specific
../data/rfc/rfc3588.txt- successfully processed answer
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt:8.2. Accounting Session State Machine
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- The following state machines MUST be supported for applications that
../data/rfc/rfc3588.txt: have an accounting portion or that require only accounting services.
../data/rfc/rfc3588.txt- The first state machine is to be observed by clients.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: See Section 9.7 for Accounting Command Codes and Section 9.8 for
../data/rfc/rfc3588.txt: Accounting AVPs.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: The server side in the accounting state machine depends in some cases
../data/rfc/rfc3588.txt- on the particular application. The Diameter base protocol defines a
../data/rfc/rfc3588.txt- default state machine that MUST be followed by all applications that
../data/rfc/rfc3588.txt- have not specified other state machines. This is the second state
../data/rfc/rfc3588.txt- machine in this section described below.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- The default server side state machine requires the reception of
../data/rfc/rfc3588.txt: accounting records in any order and at any time, and does not place
../data/rfc/rfc3588.txt- any standards requirement on the processing of these records.
../data/rfc/rfc3588.txt- Implementations of Diameter MAY perform checking, ordering,
../data/rfc/rfc3588.txt- correlation, fraud detection, and other tasks based on these records.
../data/rfc/rfc3588.txt- Both base Diameter AVPs as well as application specific AVPs MAY be
../data/rfc/rfc3588.txt- inspected as a part of these tasks. The tasks can happen either
../data/rfc/rfc3588.txt- immediately after record reception or in a post-processing phase.
../data/rfc/rfc3588.txt- However, as these tasks are typically application or even policy
../data/rfc/rfc3588.txt- dependent, they are not standardized by the Diameter specifications.
../data/rfc/rfc3588.txt: Applications MAY define requirements on when to accept accounting
../data/rfc/rfc3588.txt: records based on the used value of Accounting-Realtime-Required AVP,
../data/rfc/rfc3588.txt- credit limits checks, and so on.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- However, the Diameter base protocol defines one optional server side
../data/rfc/rfc3588.txt- state machine that MAY be followed by applications that require
../data/rfc/rfc3588.txt: keeping track of the session state at the accounting server. Note
../data/rfc/rfc3588.txt- that such tracking is incompatible with the ability to sustain long
../data/rfc/rfc3588.txt- duration connectivity problems. Therefore, the use of this state
../data/rfc/rfc3588.txt- machine is recommended only in applications where the value of the
../data/rfc/rfc3588.txt: Accounting-Realtime-Required AVP is DELIVER_AND_GRANT, and hence
../data/rfc/rfc3588.txt: accounting connectivity problems are required to cause the serviced
../data/rfc/rfc3588.txt- user to be disconnected. Otherwise, records produced by the client
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-Calhoun, et al. Standards Track [Page 96]
--
../data/rfc/rfc3588.txt- connectivity is re-established. This state machine is the third
../data/rfc/rfc3588.txt- state machine in this section. The state machine is supervised by a
../data/rfc/rfc3588.txt- supervision session timer Ts, which the value should be reasonably
../data/rfc/rfc3588.txt- higher than the Acct_Interim_Interval value. Ts MAY be set to two
../data/rfc/rfc3588.txt- times the value of the Acct_Interim_Interval so as to avoid the
../data/rfc/rfc3588.txt: accounting session in the Diameter server to change to Idle state in
../data/rfc/rfc3588.txt- case of short transient network failure.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Any event not listed in the state machines MUST be considered as an
../data/rfc/rfc3588.txt- error condition, and a corresponding answer, if applicable, MUST be
../data/rfc/rfc3588.txt- returned to the originator of the message.
--
../data/rfc/rfc3588.txt- In the state table, the event 'Failure to send' means that the
../data/rfc/rfc3588.txt- Diameter client is unable to communicate with the desired
../data/rfc/rfc3588.txt- destination. This could be due to the peer being down, or due to the
../data/rfc/rfc3588.txt- peer sending back a transient failure or temporary protocol error
../data/rfc/rfc3588.txt- notification DIAMETER_OUT_OF_SPACE, DIAMETER_TOO_BUSY, or
../data/rfc/rfc3588.txt: DIAMETER_LOOP_DETECTED in the Result-Code AVP of the Accounting
../data/rfc/rfc3588.txt- Answer command.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- The event 'Failed answer' means that the Diameter client received a
../data/rfc/rfc3588.txt: non-transient failure notification in the Accounting Answer command.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Note that the action 'Disconnect user/dev' MUST have an effect also
../data/rfc/rfc3588.txt- to the authorization session state table, e.g., cause the STR message
../data/rfc/rfc3588.txt- to be sent, if the given application has both
../data/rfc/rfc3588.txt: authentication/authorization and accounting portions.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- The states PendingS, PendingI, PendingL, PendingE and PendingB stand
../data/rfc/rfc3588.txt: for pending states to wait for an answer to an accounting request
../data/rfc/rfc3588.txt- related to a Start, Interim, Stop, Event or buffered record,
../data/rfc/rfc3588.txt- respectively.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: CLIENT, ACCOUNTING
../data/rfc/rfc3588.txt- State Event Action New State
../data/rfc/rfc3588.txt- -------------------------------------------------------------
../data/rfc/rfc3588.txt- Idle Client or device requests Send PendingS
../data/rfc/rfc3588.txt: access accounting
../data/rfc/rfc3588.txt- start req.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Idle Client or device requests Send PendingE
../data/rfc/rfc3588.txt: a one-time service accounting
../data/rfc/rfc3588.txt- event req
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Idle Records in storage Send PendingB
../data/rfc/rfc3588.txt- record
../data/rfc/rfc3588.txt-
--
../data/rfc/rfc3588.txt-Calhoun, et al. Standards Track [Page 97]
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-RFC 3588 Diameter Based Protocol September 2003
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: PendingS Successful accounting Open
../data/rfc/rfc3588.txt- start answer received
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- PendingS Failure to send and buffer Store Open
../data/rfc/rfc3588.txt- space available and realtime Start
../data/rfc/rfc3588.txt- not equal to DELIVER_AND_GRANT Record
--
../data/rfc/rfc3588.txt- PendingS Failure to send and no buffer Disconnect Idle
../data/rfc/rfc3588.txt- space available and realtime user/dev
../data/rfc/rfc3588.txt- not equal to
../data/rfc/rfc3588.txt- GRANT_AND_LOSE
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: PendingS Failed accounting start answer Open
../data/rfc/rfc3588.txt- received and realtime equal
../data/rfc/rfc3588.txt- to GRANT_AND_LOSE
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: PendingS Failed accounting start answer Disconnect Idle
../data/rfc/rfc3588.txt- received and realtime not user/dev
../data/rfc/rfc3588.txt- equal to GRANT_AND_LOSE
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- PendingS User service terminated Store PendingS
../data/rfc/rfc3588.txt- stop
../data/rfc/rfc3588.txt- record
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Open Interim interval elapses Send PendingI
../data/rfc/rfc3588.txt: accounting
../data/rfc/rfc3588.txt- interim
../data/rfc/rfc3588.txt- record
../data/rfc/rfc3588.txt- Open User service terminated Send PendingL
../data/rfc/rfc3588.txt: accounting
../data/rfc/rfc3588.txt- stop req.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: PendingI Successful accounting interim Open
../data/rfc/rfc3588.txt- answer received
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- PendingI Failure to send and (buffer Store Open
../data/rfc/rfc3588.txt- space available or old record interim
../data/rfc/rfc3588.txt- can be overwritten) and record
--
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- PendingI Failure to send and no buffer Disconnect Idle
../data/rfc/rfc3588.txt- space available and realtime user/dev
../data/rfc/rfc3588.txt- not equal to GRANT_AND_LOSE
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: PendingI Failed accounting interim Open
../data/rfc/rfc3588.txt- answer received and realtime
../data/rfc/rfc3588.txt- equal to GRANT_AND_LOSE
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: PendingI Failed accounting interim Disconnect Idle
../data/rfc/rfc3588.txt- answer received and realtime user/dev
../data/rfc/rfc3588.txt- not equal to GRANT_AND_LOSE
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- PendingI User service terminated Store PendingI
../data/rfc/rfc3588.txt- stop
../data/rfc/rfc3588.txt- record
../data/rfc/rfc3588.txt: PendingE Successful accounting Idle
../data/rfc/rfc3588.txt- event answer received
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- PendingE Failure to send and buffer Store Idle
../data/rfc/rfc3588.txt- space available event
../data/rfc/rfc3588.txt- record
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- PendingE Failure to send and no buffer Idle
../data/rfc/rfc3588.txt- space available
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: PendingE Failed accounting event answer Idle
../data/rfc/rfc3588.txt- received
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: PendingB Successful accounting answer Delete Idle
../data/rfc/rfc3588.txt- received record
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- PendingB Failure to send Idle
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: PendingB Failed accounting answer Delete Idle
../data/rfc/rfc3588.txt- received record
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: PendingL Successful accounting Idle
../data/rfc/rfc3588.txt- stop answer received
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- PendingL Failure to send and buffer Store Idle
../data/rfc/rfc3588.txt- space available stop
../data/rfc/rfc3588.txt- record
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- PendingL Failure to send and no buffer Idle
../data/rfc/rfc3588.txt- space available
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: PendingL Failed accounting stop answer Idle
../data/rfc/rfc3588.txt- received
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-Calhoun, et al. Standards Track [Page 99]
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-RFC 3588 Diameter Based Protocol September 2003
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: SERVER, STATELESS ACCOUNTING
../data/rfc/rfc3588.txt- State Event Action New State
../data/rfc/rfc3588.txt- -------------------------------------------------------------
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: Idle Accounting start request Send Idle
../data/rfc/rfc3588.txt: received, and successfully accounting
../data/rfc/rfc3588.txt- processed. start
../data/rfc/rfc3588.txt- answer
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: Idle Accounting event request Send Idle
../data/rfc/rfc3588.txt: received, and successfully accounting
../data/rfc/rfc3588.txt- processed. event
../data/rfc/rfc3588.txt- answer
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Idle Interim record received, Send Idle
../data/rfc/rfc3588.txt: and successfully processed. accounting
../data/rfc/rfc3588.txt- interim
../data/rfc/rfc3588.txt- answer
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: Idle Accounting stop request Send Idle
../data/rfc/rfc3588.txt: received, and successfully accounting
../data/rfc/rfc3588.txt- processed stop answer
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: Idle Accounting request received, Send Idle
../data/rfc/rfc3588.txt: no space left to store accounting
../data/rfc/rfc3588.txt- records answer,
../data/rfc/rfc3588.txt- Result-Code
../data/rfc/rfc3588.txt- = OUT_OF_
../data/rfc/rfc3588.txt- SPACE
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: SERVER, STATEFUL ACCOUNTING
../data/rfc/rfc3588.txt- State Event Action New State
../data/rfc/rfc3588.txt- -------------------------------------------------------------
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: Idle Accounting start request Send Open
../data/rfc/rfc3588.txt: received, and successfully accounting
../data/rfc/rfc3588.txt- processed. start
../data/rfc/rfc3588.txt- answer,
../data/rfc/rfc3588.txt- Start Ts
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: Idle Accounting event request Send Idle
../data/rfc/rfc3588.txt: received, and successfully accounting
../data/rfc/rfc3588.txt- processed. event
../data/rfc/rfc3588.txt- answer
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
--
../data/rfc/rfc3588.txt-Calhoun, et al. Standards Track [Page 100]
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-RFC 3588 Diameter Based Protocol September 2003
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: Idle Accounting request received, Send Idle
../data/rfc/rfc3588.txt: no space left to store accounting
../data/rfc/rfc3588.txt- records answer,
../data/rfc/rfc3588.txt- Result-Code
../data/rfc/rfc3588.txt- = OUT_OF_
../data/rfc/rfc3588.txt- SPACE
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Open Interim record received, Send Open
../data/rfc/rfc3588.txt: and successfully processed. accounting
../data/rfc/rfc3588.txt- interim
../data/rfc/rfc3588.txt- answer,
../data/rfc/rfc3588.txt- Restart Ts
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: Open Accounting stop request Send Idle
../data/rfc/rfc3588.txt: received, and successfully accounting
../data/rfc/rfc3588.txt- processed stop answer,
../data/rfc/rfc3588.txt- Stop Ts
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: Open Accounting request received, Send Idle
../data/rfc/rfc3588.txt: no space left to store accounting
../data/rfc/rfc3588.txt- records answer,
../data/rfc/rfc3588.txt- Result-Code
../data/rfc/rfc3588.txt- = OUT_OF_
../data/rfc/rfc3588.txt- SPACE,
../data/rfc/rfc3588.txt- Stop Ts
--
../data/rfc/rfc3588.txt- Diameter Header (see Section 3).
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- The Session-Id MUST be globally and eternally unique, as it is meant
../data/rfc/rfc3588.txt- to uniquely identify a user session without reference to any other
../data/rfc/rfc3588.txt- information, and may be needed to correlate historical authentication
../data/rfc/rfc3588.txt: information with accounting information. The Session-Id includes a
../data/rfc/rfc3588.txt- mandatory portion and an implementation-defined portion; a
../data/rfc/rfc3588.txt- recommended format for the implementation-defined portion is outlined
../data/rfc/rfc3588.txt- below.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- The Session-Id MUST begin with the sender's identity encoded in the
--
../data/rfc/rfc3588.txt- Example, in which there is an optional value:
../data/rfc/rfc3588.txt- accesspoint7.acme.com;1876543210;523;mobile@200.1.1.88
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- The Session-Id is created by the Diameter application initiating the
../data/rfc/rfc3588.txt- session, which in most cases is done by the client. Note that a
../data/rfc/rfc3588.txt: Session-Id MAY be used for both the authorization and accounting
../data/rfc/rfc3588.txt- commands of a given application.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-8.9. Authorization-Lifetime AVP
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- The Authorization-Lifetime AVP (AVP Code 291) is of type Unsigned32
--
../data/rfc/rfc3588.txt- When set, the STR message for this session MUST NOT include the
../data/rfc/rfc3588.txt- Destination-Host AVP. When cleared, the default value, the
../data/rfc/rfc3588.txt- Destination-Host AVP MUST be present in the STR message for this
../data/rfc/rfc3588.txt- session.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: ACCOUNTING 4
../data/rfc/rfc3588.txt: When set, all accounting messages for this session MUST NOT
../data/rfc/rfc3588.txt- include the Destination-Host AVP. When cleared, the default
../data/rfc/rfc3588.txt- value, the Destination-Host AVP, if known, MUST be present in all
../data/rfc/rfc3588.txt: accounting messages for this session.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-8.18. Session-Server-Failover AVP
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- The Session-Server-Failover AVP (AVP Code 271) is of type Enumerated,
../data/rfc/rfc3588.txt- and MAY be present in application-specific authorization answer
--
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- The Class AVP (AVP Code 25) is of type OctetString and is used to by
../data/rfc/rfc3588.txt- Diameter servers to return state information to the access device.
../data/rfc/rfc3588.txt- When one or more Class AVPs are present in application-specific
../data/rfc/rfc3588.txt- authorization answer messages, they MUST be present in subsequent
../data/rfc/rfc3588.txt: re-authorization, session termination and accounting messages. Class
../data/rfc/rfc3588.txt- AVPs found in a re-authorization answer message override the ones
../data/rfc/rfc3588.txt- found in any previous authorization answer message. Diameter server
../data/rfc/rfc3588.txt- implementations SHOULD NOT return Class AVPs that require more than
../data/rfc/rfc3588.txt- 4096 bytes of storage on the Diameter client. A Diameter client that
../data/rfc/rfc3588.txt- receives Class AVPs whose size exceeds local available storage MUST
--
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-8.21. Event-Timestamp AVP
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- The Event-Timestamp (AVP Code 55) is of type Time, and MAY be
../data/rfc/rfc3588.txt: included in an Accounting-Request and Accounting-Answer messages to
../data/rfc/rfc3588.txt- record the time that the reported event occurred, in seconds since
../data/rfc/rfc3588.txt- January 1, 1900 00:00 UTC.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt:9. Accounting
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: This accounting protocol is based on a server directed model with
../data/rfc/rfc3588.txt: capabilities for real-time delivery of accounting information.
../data/rfc/rfc3588.txt- Several fault resilience methods [ACCMGMT] have been built in to the
../data/rfc/rfc3588.txt: protocol in order minimize loss of accounting data in various fault
../data/rfc/rfc3588.txt- situations and under different assumptions about the capabilities of
../data/rfc/rfc3588.txt- the used devices.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-9.1. Server Directed Model
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- The server directed model means that the device generating the
../data/rfc/rfc3588.txt: accounting data gets information from either the authorization server
../data/rfc/rfc3588.txt: (if contacted) or the accounting server regarding the way accounting
../data/rfc/rfc3588.txt: data shall be forwarded. This information includes accounting record
../data/rfc/rfc3588.txt- timeliness requirements.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: As discussed in [ACCMGMT], real-time transfer of accounting records
../data/rfc/rfc3588.txt- is a requirement, such as the need to perform credit limit checks and
../data/rfc/rfc3588.txt: fraud detection. Note that batch accounting is not a requirement,
../data/rfc/rfc3588.txt- and is therefore not supported by Diameter. Should batched
../data/rfc/rfc3588.txt: accounting be required in the future, a new Diameter application will
../data/rfc/rfc3588.txt- need to be created, or it could be handled using another protocol.
../data/rfc/rfc3588.txt: Note, however, that even if at the Diameter layer accounting requests
../data/rfc/rfc3588.txt- are processed one by one, transport protocols used under Diameter
../data/rfc/rfc3588.txt- typically batch several requests in the same packet under heavy
../data/rfc/rfc3588.txt- traffic conditions. This may be sufficient for many applications.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- The authorization server (chain) directs the selection of proper
../data/rfc/rfc3588.txt- transfer strategy, based on its knowledge of the user and
../data/rfc/rfc3588.txt- relationships of roaming partnerships. The server (or agents) uses
../data/rfc/rfc3588.txt: the Acct-Interim-Interval and Accounting-Realtime-Required AVPs to
../data/rfc/rfc3588.txt- control the operation of the Diameter peer operating as a client.
../data/rfc/rfc3588.txt- The Acct-Interim-Interval AVP, when present, instructs the Diameter
../data/rfc/rfc3588.txt: node acting as a client to produce accounting records continuously
../data/rfc/rfc3588.txt: even during a session. Accounting-Realtime-Required AVP is used to
../data/rfc/rfc3588.txt: control the behavior of the client when the transfer of accounting
../data/rfc/rfc3588.txt- records from the Diameter client is delayed or unsuccessful.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
--
../data/rfc/rfc3588.txt-Calhoun, et al. Standards Track [Page 115]
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-RFC 3588 Diameter Based Protocol September 2003
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: The Diameter accounting server MAY override the interim interval or
../data/rfc/rfc3588.txt- the realtime requirements by including the Acct-Interim-Interval or
../data/rfc/rfc3588.txt: Accounting-Realtime-Required AVP in the Accounting-Answer message.
../data/rfc/rfc3588.txt- When one of these AVPs is present, the latest value received SHOULD
../data/rfc/rfc3588.txt: be used in further accounting activities for the same session.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-9.2. Protocol Messages
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- A Diameter node that receives a successful authentication and/or
../data/rfc/rfc3588.txt- authorization messages from the Home AAA server MUST collect
../data/rfc/rfc3588.txt: accounting information for the session. The Accounting-Request
../data/rfc/rfc3588.txt: message is used to transmit the accounting information to the Home
../data/rfc/rfc3588.txt: AAA server, which MUST reply with the Accounting-Answer message to
../data/rfc/rfc3588.txt: confirm reception. The Accounting-Answer message includes the
../data/rfc/rfc3588.txt- Result-Code AVP, which MAY indicate that an error was present in the
../data/rfc/rfc3588.txt: accounting message. A rejected Accounting-Request message MAY cause
../data/rfc/rfc3588.txt- the user's session to be terminated, depending on the value of the
../data/rfc/rfc3588.txt: Accounting-Realtime-Required AVP received earlier for the session in
../data/rfc/rfc3588.txt- question.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: Each Diameter Accounting protocol message MAY be compressed, in order
../data/rfc/rfc3588.txt- to reduce network bandwidth usage. If IPsec and IKE are used to
../data/rfc/rfc3588.txt- secure the Diameter session, then IP compression [IPComp] MAY be used
../data/rfc/rfc3588.txt- and IKE [IKE] MAY be used to negotiate the compression parameters.
../data/rfc/rfc3588.txt- If TLS is used to secure the Diameter session, then TLS compression
../data/rfc/rfc3588.txt- [TLS] MAY be used.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-9.3. Application document requirements
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Each Diameter application (e.g., NASREQ, MobileIP), MUST define their
../data/rfc/rfc3588.txt: Service-Specific AVPs that MUST be present in the Accounting-Request
../data/rfc/rfc3588.txt: message in a section entitled "Accounting AVPs". The application
../data/rfc/rfc3588.txt- MUST assume that the AVPs described in this document will be present
../data/rfc/rfc3588.txt: in all Accounting messages, so only their respective service-specific
../data/rfc/rfc3588.txt- AVPs need to be defined in this section.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-9.4. Fault Resilience
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Diameter Base protocol mechanisms are used to overcome small message
../data/rfc/rfc3588.txt- loss and network faults of temporary nature.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Diameter peers acting as clients MUST implement the use of failover
../data/rfc/rfc3588.txt- to guard against server failures and certain network failures.
../data/rfc/rfc3588.txt- Diameter peers acting as agents or related off-line processing
../data/rfc/rfc3588.txt: systems MUST detect duplicate accounting records caused by the
../data/rfc/rfc3588.txt- sending of same record to several servers and duplication of messages
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
--
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-RFC 3588 Diameter Based Protocol September 2003
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- in transit. This detection MUST be based on the inspection of the
../data/rfc/rfc3588.txt: Session-Id and Accounting-Record-Number AVP pairs. Appendix C
../data/rfc/rfc3588.txt- discusses duplicate detection needs and implementation issues.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Diameter clients MAY have non-volatile memory for the safe storage of
../data/rfc/rfc3588.txt: accounting records over reboots or extended network failures, network
../data/rfc/rfc3588.txt- partitions, and server failures. If such memory is available, the
../data/rfc/rfc3588.txt: client SHOULD store new accounting records there as soon as the
../data/rfc/rfc3588.txt- records are created and until a positive acknowledgement of their
../data/rfc/rfc3588.txt- reception from the Diameter Server has been received. Upon a reboot,
../data/rfc/rfc3588.txt- the client MUST starting sending the records in the non-volatile
../data/rfc/rfc3588.txt: memory to the accounting server with appropriate modifications in
../data/rfc/rfc3588.txt- termination cause, session length, and other relevant information in
../data/rfc/rfc3588.txt- the records.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- A further application of this protocol may include AVPs to control
../data/rfc/rfc3588.txt: how many accounting records may at most be stored in the Diameter
../data/rfc/rfc3588.txt- client without committing them to the non-volatile memory or
../data/rfc/rfc3588.txt- transferring them to the Diameter server.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: The client SHOULD NOT remove the accounting data from any of its
../data/rfc/rfc3588.txt: memory areas before the correct Accounting-Answer has been received.
../data/rfc/rfc3588.txt- The client MAY remove oldest, undelivered or yet unacknowledged
../data/rfc/rfc3588.txt: accounting data if it runs out of resources such as memory. It is an
../data/rfc/rfc3588.txt- implementation dependent matter for the client to accept new sessions
../data/rfc/rfc3588.txt- under this condition.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt:9.5. Accounting Records
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: In all accounting records, the Session-Id AVP MUST be present; the
../data/rfc/rfc3588.txt- User-Name AVP MUST be present if it is available to the Diameter
../data/rfc/rfc3588.txt- client. If strong authentication across agents is required, end-to-
../data/rfc/rfc3588.txt- end security may be used for authentication purposes.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: Different types of accounting records are sent depending on the
../data/rfc/rfc3588.txt- actual type of accounted service and the authorization server's
../data/rfc/rfc3588.txt: directions for interim accounting. If the accounted service is a
../data/rfc/rfc3588.txt- one-time event, meaning that the start and stop of the event are
../data/rfc/rfc3588.txt: simultaneous, then the Accounting-Record-Type AVP MUST be present and
../data/rfc/rfc3588.txt- set to the value EVENT_RECORD.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- If the accounted service is of a measurable length, then the AVP MUST
../data/rfc/rfc3588.txt- use the values START_RECORD, STOP_RECORD, and possibly,
../data/rfc/rfc3588.txt- INTERIM_RECORD. If the authorization server has not directed interim
../data/rfc/rfc3588.txt: accounting to be enabled for the session, two accounting records MUST
../data/rfc/rfc3588.txt- be generated for each service of type session. When the initial
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
--
../data/rfc/rfc3588.txt-Calhoun, et al. Standards Track [Page 117]
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-RFC 3588 Diameter Based Protocol September 2003
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: Accounting-Request for a given session is sent, the Accounting-
../data/rfc/rfc3588.txt- Record-Type AVP MUST be set to the value START_RECORD. When the last
../data/rfc/rfc3588.txt: Accounting-Request is sent, the value MUST be STOP_RECORD.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: If the authorization server has directed interim accounting to be
../data/rfc/rfc3588.txt- enabled, the Diameter client MUST produce additional records between
../data/rfc/rfc3588.txt- the START_RECORD and STOP_RECORD, marked INTERIM_RECORD. The
../data/rfc/rfc3588.txt- production of these records is directed by Acct-Interim-Interval as
../data/rfc/rfc3588.txt- well as any re-authentication or re-authorization of the session. The
../data/rfc/rfc3588.txt: Diameter client MUST overwrite any previous interim accounting
../data/rfc/rfc3588.txt- records that are locally stored for delivery, if a new record is
../data/rfc/rfc3588.txt- being generated for the same session. This ensures that only one
../data/rfc/rfc3588.txt- pending interim record can exist on an access device for any given
../data/rfc/rfc3588.txt- session.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: A particular value of Accounting-Sub-Session-Id MUST appear only in
../data/rfc/rfc3588.txt: one sequence of accounting records from a DIAMETER client, except for
../data/rfc/rfc3588.txt- the purposes of retransmission. The one sequence that is sent MUST
../data/rfc/rfc3588.txt: be either one record with Accounting-Record-Type AVP set to the value
../data/rfc/rfc3588.txt- EVENT_RECORD, or several records starting with one having the value
../data/rfc/rfc3588.txt- START_RECORD, followed by zero or more INTERIM_RECORD and a single
../data/rfc/rfc3588.txt- STOP_RECORD. A particular Diameter application specification MUST
../data/rfc/rfc3588.txt- define the type of sequences that MUST be used.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt:9.6. Correlation of Accounting Records
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- The Diameter protocol's Session-Id AVP, which is globally unique (see
../data/rfc/rfc3588.txt- Section 8.8), is used during the authorization phase to identify a
../data/rfc/rfc3588.txt- particular session. Services that do not require any authorization
../data/rfc/rfc3588.txt: still use the Session-Id AVP to identify sessions. Accounting
../data/rfc/rfc3588.txt- messages MAY use a different Session-Id from that sent in
../data/rfc/rfc3588.txt- authorization messages. Specific applications MAY require different
../data/rfc/rfc3588.txt: a Session-ID for accounting messages.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- However, there are certain applications that require multiple
../data/rfc/rfc3588.txt: accounting sub-sessions. Such applications would send messages with
../data/rfc/rfc3588.txt: a constant Session-Id AVP, but a different Accounting-Sub-Session-Id
../data/rfc/rfc3588.txt- AVP. In these cases, correlation is performed using the Session-Id.
../data/rfc/rfc3588.txt- It is important to note that receiving a STOP_RECORD with no
../data/rfc/rfc3588.txt: Accounting-Sub-Session-Id AVP when sub-sessions were originally used
../data/rfc/rfc3588.txt- in the START_RECORD messages implies that all sub-sessions are
../data/rfc/rfc3588.txt- terminated.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Furthermore, there are certain applications where a user receives
../data/rfc/rfc3588.txt- service from different access devices (e.g., Mobile IPv4), each with
--
../data/rfc/rfc3588.txt-RFC 3588 Diameter Based Protocol September 2003
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- determines that a request is for an existing session SHOULD include
../data/rfc/rfc3588.txt- the Acct-Multi-Session-Id AVP, which the access device MUST include
../data/rfc/rfc3588.txt: in all subsequent accounting messages.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- The Acct-Multi-Session-Id AVP MAY include the value of the original
../data/rfc/rfc3588.txt- Session-Id. It's contents are implementation specific, but MUST be
../data/rfc/rfc3588.txt- globally unique across other Acct-Multi-Session-Id, and MUST NOT
../data/rfc/rfc3588.txt- change during the life of a session.
--
../data/rfc/rfc3588.txt- session that is being accounted, and MAY define the concept of a
../data/rfc/rfc3588.txt- multi-session. For instance, the NASREQ DIAMETER application treats
../data/rfc/rfc3588.txt- a single PPP connection to a Network Access Server as one session,
../data/rfc/rfc3588.txt- and a set of Multilink PPP sessions as one multi-session.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt:9.7. Accounting Command-Codes
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- This section defines Command-Code values that MUST be supported by
../data/rfc/rfc3588.txt: all Diameter implementations that provide Accounting services.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt:9.7.1. Accounting-Request
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: The Accounting-Request (ACR) command, indicated by the Command-Code
../data/rfc/rfc3588.txt- field set to 271 and the Command Flags' 'R' bit set, is sent by a
../data/rfc/rfc3588.txt: Diameter node, acting as a client, in order to exchange accounting
../data/rfc/rfc3588.txt- information with a peer.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs
../data/rfc/rfc3588.txt- MUST be present. If the Vendor-Specific-Application-Id grouped AVP
../data/rfc/rfc3588.txt- is present, it must have an Acct-Application-Id inside.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: The AVP listed below SHOULD include service specific accounting AVPs,
../data/rfc/rfc3588.txt- as described in Section 9.3.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
--
../data/rfc/rfc3588.txt- <ACR> ::= < Diameter Header: 271, REQ, PXY >
../data/rfc/rfc3588.txt- < Session-Id >
../data/rfc/rfc3588.txt- { Origin-Host }
../data/rfc/rfc3588.txt- { Origin-Realm }
../data/rfc/rfc3588.txt- { Destination-Realm }
../data/rfc/rfc3588.txt: { Accounting-Record-Type }
../data/rfc/rfc3588.txt: { Accounting-Record-Number }
../data/rfc/rfc3588.txt- [ Acct-Application-Id ]
../data/rfc/rfc3588.txt- [ Vendor-Specific-Application-Id ]
../data/rfc/rfc3588.txt- [ User-Name ]
../data/rfc/rfc3588.txt: [ Accounting-Sub-Session-Id ]
../data/rfc/rfc3588.txt- [ Acct-Session-Id ]
../data/rfc/rfc3588.txt- [ Acct-Multi-Session-Id ]
../data/rfc/rfc3588.txt- [ Acct-Interim-Interval ]
../data/rfc/rfc3588.txt: [ Accounting-Realtime-Required ]
../data/rfc/rfc3588.txt- [ Origin-State-Id ]
../data/rfc/rfc3588.txt- [ Event-Timestamp ]
../data/rfc/rfc3588.txt- * [ Proxy-Info ]
../data/rfc/rfc3588.txt- * [ Route-Record ]
../data/rfc/rfc3588.txt- * [ AVP ]
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt:9.7.2. Accounting-Answer
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: The Accounting-Answer (ACA) command, indicated by the Command-Code
../data/rfc/rfc3588.txt- field set to 271 and the Command Flags' 'R' bit cleared, is used to
../data/rfc/rfc3588.txt: acknowledge an Accounting-Request command. The Accounting-Answer
../data/rfc/rfc3588.txt- command contains the same Session-Id and includes the usage AVPs only
../data/rfc/rfc3588.txt- if CMS is in use when sending this command. Note that the inclusion
../data/rfc/rfc3588.txt- of the usage AVPs when CMS is not being used leads to unnecessarily
../data/rfc/rfc3588.txt- large answer messages, and can not be used as a server's proof of the
../data/rfc/rfc3588.txt: receipt of these AVPs in an end-to-end fashion. If the Accounting-
../data/rfc/rfc3588.txt- Request was protected by end-to-end security, then the corresponding
../data/rfc/rfc3588.txt- ACA message MUST be protected by end-to-end security.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Only the target Diameter Server, known as the home Diameter Server,
../data/rfc/rfc3588.txt: SHOULD respond with the Accounting-Answer command.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs
../data/rfc/rfc3588.txt- MUST be present. If the Vendor-Specific-Application-Id grouped AVP
../data/rfc/rfc3588.txt- is present, it must have an Acct-Application-Id inside.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: The AVP listed below SHOULD include service specific accounting AVPs,
../data/rfc/rfc3588.txt- as described in Section 9.3.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
--
../data/rfc/rfc3588.txt- <ACA> ::= < Diameter Header: 271, PXY >
../data/rfc/rfc3588.txt- < Session-Id >
../data/rfc/rfc3588.txt- { Result-Code }
../data/rfc/rfc3588.txt- { Origin-Host }
../data/rfc/rfc3588.txt- { Origin-Realm }
../data/rfc/rfc3588.txt: { Accounting-Record-Type }
../data/rfc/rfc3588.txt: { Accounting-Record-Number }
../data/rfc/rfc3588.txt- [ Acct-Application-Id ]
../data/rfc/rfc3588.txt- [ Vendor-Specific-Application-Id ]
../data/rfc/rfc3588.txt- [ User-Name ]
../data/rfc/rfc3588.txt: [ Accounting-Sub-Session-Id ]
../data/rfc/rfc3588.txt- [ Acct-Session-Id ]
../data/rfc/rfc3588.txt- [ Acct-Multi-Session-Id ]
../data/rfc/rfc3588.txt- [ Error-Reporting-Host ]
../data/rfc/rfc3588.txt- [ Acct-Interim-Interval ]
../data/rfc/rfc3588.txt: [ Accounting-Realtime-Required ]
../data/rfc/rfc3588.txt- [ Origin-State-Id ]
../data/rfc/rfc3588.txt- [ Event-Timestamp ]
../data/rfc/rfc3588.txt- * [ Proxy-Info ]
../data/rfc/rfc3588.txt- * [ AVP ]
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt:9.8. Accounting AVPs
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: This section contains AVPs that describe accounting usage information
../data/rfc/rfc3588.txt- related to a specific session.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt:9.8.1. Accounting-Record-Type AVP
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: The Accounting-Record-Type AVP (AVP Code 480) is of type Enumerated
../data/rfc/rfc3588.txt: and contains the type of accounting record being sent. The following
../data/rfc/rfc3588.txt: values are currently defined for the Accounting-Record-Type AVP:
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- EVENT_RECORD 1
../data/rfc/rfc3588.txt: An Accounting Event Record is used to indicate that a one-time
../data/rfc/rfc3588.txt- event has occurred (meaning that the start and end of the event
../data/rfc/rfc3588.txt- are simultaneous). This record contains all information relevant
../data/rfc/rfc3588.txt- to the service, and is the only record of the service.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- START_RECORD 2
../data/rfc/rfc3588.txt: An Accounting Start, Interim, and Stop Records are used to
../data/rfc/rfc3588.txt- indicate that a service of a measurable length has been given. An
../data/rfc/rfc3588.txt: Accounting Start Record is used to initiate an accounting session,
../data/rfc/rfc3588.txt: and contains accounting information that is relevant to the
../data/rfc/rfc3588.txt- initiation of the session.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
--
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-RFC 3588 Diameter Based Protocol September 2003
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- INTERIM_RECORD 3
../data/rfc/rfc3588.txt: An Interim Accounting Record contains cumulative accounting
../data/rfc/rfc3588.txt: information for an existing accounting session. Interim
../data/rfc/rfc3588.txt: Accounting Records SHOULD be sent every time a re-authentication
../data/rfc/rfc3588.txt- or re-authorization occurs. Further, additional interim record
../data/rfc/rfc3588.txt- triggers MAY be defined by application-specific Diameter
../data/rfc/rfc3588.txt- applications. The selection of whether to use INTERIM_RECORD
../data/rfc/rfc3588.txt- records is done by the Acct-Interim-Interval AVP.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- STOP_RECORD 4
../data/rfc/rfc3588.txt: An Accounting Stop Record is sent to terminate an accounting
../data/rfc/rfc3588.txt: session and contains cumulative accounting information relevant to
../data/rfc/rfc3588.txt- the existing session.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-9.8.2. Acct-Interim-Interval
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- The Acct-Interim-Interval AVP (AVP Code 85) is of type Unsigned32 and
../data/rfc/rfc3588.txt- is sent from the Diameter home authorization server to the Diameter
../data/rfc/rfc3588.txt- client. The client uses information in this AVP to decide how and
../data/rfc/rfc3588.txt: when to produce accounting records. With different values in this
../data/rfc/rfc3588.txt: AVP, service sessions can result in one, two, or two+N accounting
../data/rfc/rfc3588.txt- records, based on the needs of the home-organization. The following
../data/rfc/rfc3588.txt: accounting record production behavior is directed by the inclusion of
../data/rfc/rfc3588.txt- this AVP:
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- 1. The omission of the Acct-Interim-Interval AVP or its inclusion
../data/rfc/rfc3588.txt- with Value field set to 0 means that EVENT_RECORD, START_RECORD,
../data/rfc/rfc3588.txt- and STOP_RECORD are produced, as appropriate for the service.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- 2. The inclusion of the AVP with Value field set to a non-zero value
../data/rfc/rfc3588.txt- means that INTERIM_RECORD records MUST be produced between the
../data/rfc/rfc3588.txt- START_RECORD and STOP_RECORD records. The Value field of this AVP
../data/rfc/rfc3588.txt- is the nominal interval between these records in seconds. The
../data/rfc/rfc3588.txt: Diameter node that originates the accounting information, known as
../data/rfc/rfc3588.txt- the client, MUST produce the first INTERIM_RECORD record roughly
../data/rfc/rfc3588.txt- at the time when this nominal interval has elapsed from the
../data/rfc/rfc3588.txt- START_RECORD, the next one again as the interval has elapsed once
../data/rfc/rfc3588.txt- more, and so on until the session ends and a STOP_RECORD record is
../data/rfc/rfc3588.txt- produced.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- The client MUST ensure that the interim record production times
../data/rfc/rfc3588.txt: are randomized so that large accounting message storms are not
../data/rfc/rfc3588.txt- created either among records or around a common service start
../data/rfc/rfc3588.txt- time.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
--
../data/rfc/rfc3588.txt-Calhoun, et al. Standards Track [Page 122]
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-RFC 3588 Diameter Based Protocol September 2003
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt:9.8.3. Accounting-Record-Number AVP
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: The Accounting-Record-Number AVP (AVP Code 485) is of type Unsigned32
../data/rfc/rfc3588.txt- and identifies this record within one session. As Session-Id AVPs
../data/rfc/rfc3588.txt: are globally unique, the combination of Session-Id and Accounting-
../data/rfc/rfc3588.txt- Record-Number AVPs is also globally unique, and can be used in
../data/rfc/rfc3588.txt: matching accounting records with confirmations. An easy way to
../data/rfc/rfc3588.txt- produce unique numbers is to set the value to 0 for records of type
../data/rfc/rfc3588.txt- EVENT_RECORD and START_RECORD, and set the value to 1 for the first
../data/rfc/rfc3588.txt- INTERIM_RECORD, 2 for the second, and so on until the value for
../data/rfc/rfc3588.txt- STOP_RECORD is one more than for the last INTERIM_RECORD.
../data/rfc/rfc3588.txt-
--
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-9.8.5. Acct-Multi-Session-Id AVP
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- The Acct-Multi-Session-Id AVP (AVP Code 50) is of type UTF8String,
../data/rfc/rfc3588.txt- following the format specified in Section 8.8. The Acct-Multi-
../data/rfc/rfc3588.txt: Session-Id AVP is used to link together multiple related accounting
../data/rfc/rfc3588.txt- sessions, where each session would have a unique Session-Id, but the
../data/rfc/rfc3588.txt- same Acct-Multi-Session-Id AVP. This AVP MAY be returned by the
../data/rfc/rfc3588.txt- Diameter server in an authorization answer, and MUST be used in all
../data/rfc/rfc3588.txt: accounting messages for the given session.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt:9.8.6. Accounting-Sub-Session-Id AVP
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: The Accounting-Sub-Session-Id AVP (AVP Code 287) is of type
../data/rfc/rfc3588.txt: Unsigned64 and contains the accounting sub-session identifier. The
../data/rfc/rfc3588.txt- combination of the Session-Id and this AVP MUST be unique per sub-
../data/rfc/rfc3588.txt- session, and the value of this AVP MUST be monotonically increased by
../data/rfc/rfc3588.txt- one for all new sub-sessions. The absence of this AVP implies no
../data/rfc/rfc3588.txt: sub-sessions are in use, with the exception of an Accounting-Request
../data/rfc/rfc3588.txt: whose Accounting-Record-Type is set to STOP_RECORD. A STOP_RECORD
../data/rfc/rfc3588.txt: message with no Accounting-Sub-Session-Id AVP present will signal the
../data/rfc/rfc3588.txt- termination of all sub-sessions for a given Session-Id.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt:9.8.7. Accounting-Realtime-Required AVP
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: The Accounting-Realtime-Required AVP (AVP Code 483) is of type
../data/rfc/rfc3588.txt- Enumerated and is sent from the Diameter home authorization server to
../data/rfc/rfc3588.txt: the Diameter client or in the Accounting-Answer from the accounting
../data/rfc/rfc3588.txt- server. The client uses information in this AVP to decide what to do
../data/rfc/rfc3588.txt: if the sending of accounting records to the accounting server has
../data/rfc/rfc3588.txt- been temporarily prevented due to, for instance, a network problem.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-Calhoun, et al. Standards Track [Page 123]
--
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- DELIVER_AND_GRANT 1
../data/rfc/rfc3588.txt- The AVP with Value field set to DELIVER_AND_GRANT means that the
../data/rfc/rfc3588.txt- service MUST only be granted as long as there is a connection to
../data/rfc/rfc3588.txt: an accounting server. Note that the set of alternative accounting
../data/rfc/rfc3588.txt- servers are treated as one server in this sense. Having to move
../data/rfc/rfc3588.txt: the accounting record stream to a backup server is not a reason to
../data/rfc/rfc3588.txt- discontinue the service to the user.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- GRANT_AND_STORE 2
../data/rfc/rfc3588.txt- The AVP with Value field set to GRANT_AND_STORE means that service
../data/rfc/rfc3588.txt- SHOULD be granted if there is a connection, or as long as records
--
../data/rfc/rfc3588.txt- 1+ At least one instance of the AVP MUST be present in the
../data/rfc/rfc3588.txt- message.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-10.1. Base Protocol Command AVP Table
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: The table in this section is limited to the non-accounting Command
../data/rfc/rfc3588.txt- Codes defined in this specification.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
--
../data/rfc/rfc3588.txt- +---+---+---+---+---+---+---+---+---+---+---+---+
../data/rfc/rfc3588.txt- Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA|
../data/rfc/rfc3588.txt- --------------------+---+---+---+---+---+---+---+---+---+---+---+---+
../data/rfc/rfc3588.txt- Acct-Interim- |0 |0 |0 |0 |0 |0 |0-1|0 |0 |0 |0 |0 |
../data/rfc/rfc3588.txt- Interval | | | | | | | | | | | | |
../data/rfc/rfc3588.txt: Accounting-Realtime-|0 |0 |0 |0 |0 |0 |0-1|0 |0 |0 |0 |0 |
../data/rfc/rfc3588.txt- Required | | | | | | | | | | | | |
../data/rfc/rfc3588.txt- Acct-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
../data/rfc/rfc3588.txt- Auth-Application-Id |0+ |0+ |0 |0 |0 |0 |1 |0 |1 |0 |1 |0 |
../data/rfc/rfc3588.txt- Auth-Grace-Period |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
../data/rfc/rfc3588.txt- Auth-Request-Type |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
--
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Vendor-Specific- |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
../data/rfc/rfc3588.txt- Application-Id | | | | | | | | | | | | |
../data/rfc/rfc3588.txt- --------------------+---+---+---+---+---+---+---+---+---+---+---+---+
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt:10.2. Accounting AVP Table
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- The table in this section is used to represent which AVPs defined in
../data/rfc/rfc3588.txt: this document are to be present in the Accounting messages. These
../data/rfc/rfc3588.txt- AVP occurrence requirements are guidelines, which may be expanded,
../data/rfc/rfc3588.txt- and/or overridden by application-specific requirements in the
../data/rfc/rfc3588.txt- Diameter applications documents.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- +-----------+
--
../data/rfc/rfc3588.txt- +-----+-----+
../data/rfc/rfc3588.txt- Attribute Name | ACR | ACA |
../data/rfc/rfc3588.txt- ------------------------------+-----+-----+
../data/rfc/rfc3588.txt- Acct-Interim-Interval | 0-1 | 0-1 |
../data/rfc/rfc3588.txt- Acct-Multi-Session-Id | 0-1 | 0-1 |
../data/rfc/rfc3588.txt: Accounting-Record-Number | 1 | 1 |
../data/rfc/rfc3588.txt: Accounting-Record-Type | 1 | 1 |
../data/rfc/rfc3588.txt- Acct-Session-Id | 0-1 | 0-1 |
../data/rfc/rfc3588.txt: Accounting-Sub-Session-Id | 0-1 | 0-1 |
../data/rfc/rfc3588.txt: Accounting-Realtime-Required | 0-1 | 0-1 |
../data/rfc/rfc3588.txt- Acct-Application-Id | 0-1 | 0-1 |
../data/rfc/rfc3588.txt- Auth-Application-Id | 0 | 0 |
../data/rfc/rfc3588.txt- Class | 0+ | 0+ |
../data/rfc/rfc3588.txt- Destination-Host | 0-1 | 0 |
../data/rfc/rfc3588.txt- Destination-Realm | 1 | 0 |
--
../data/rfc/rfc3588.txt- This section explains the criteria to be used by the IANA for
../data/rfc/rfc3588.txt- assignment of numbers within namespaces defined within this document.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Diameter is not intended as a general purpose protocol, and
../data/rfc/rfc3588.txt- allocations SHOULD NOT be made for purposes unrelated to
../data/rfc/rfc3588.txt: authentication, authorization or accounting.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- For registration requests where a Designated Expert should be
../data/rfc/rfc3588.txt- consulted, the responsible IESG area director should appoint the
../data/rfc/rfc3588.txt- Designated Expert. For Designated Expert with Specification
../data/rfc/rfc3588.txt- Required, the request is posted to the AAA WG mailing list (or, if it
--
../data/rfc/rfc3588.txt- following values are allocated.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Diameter Common Messages 0
../data/rfc/rfc3588.txt- NASREQ 1 [NASREQ]
../data/rfc/rfc3588.txt- Mobile-IP 2 [DIAMMIP]
../data/rfc/rfc3588.txt: Diameter Base Accounting 3
../data/rfc/rfc3588.txt- Relay 0xffffffff
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Assignment of standards-track application IDs are by Designated
../data/rfc/rfc3588.txt- Expert with Specification Required [IANA].
../data/rfc/rfc3588.txt-
--
../data/rfc/rfc3588.txt-Calhoun, et al. Standards Track [Page 129]
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-RFC 3588 Diameter Based Protocol September 2003
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt:11.4.2. Accounting-Record-Type AVP Values
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: As defined in Section 9.8.1, the Accounting-Record-Type AVP (AVP Code
../data/rfc/rfc3588.txt- 480) defines the values 1-4. All remaining values are available for
../data/rfc/rfc3588.txt- assignment via IETF Consensus [IANA].
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-11.4.3. Termination-Cause AVP Values
../data/rfc/rfc3588.txt-
--
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- As defined in Section 8.12, the Re-Auth-Request-Type AVP (AVP Code
../data/rfc/rfc3588.txt- 285) defines the values 0-1. All remaining values are available for
../data/rfc/rfc3588.txt- assignment via IETF Consensus [IANA].
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt:11.4.11. Accounting-Realtime-Required AVP Values
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: As defined in Section 9.8.7, the Accounting-Realtime-Required AVP
../data/rfc/rfc3588.txt- (AVP Code 483) defines the values 1-3. All remaining values are
../data/rfc/rfc3588.txt- available for assignment via IETF Consensus [IANA].
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-11.4.12. Inband-Security-Id AVP (code 299)
../data/rfc/rfc3588.txt-
--
../data/rfc/rfc3588.txt-14. References
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-14.1. Normative References
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- [AAATRANS] Aboba, B. and J. Wood, "Authentication, Authorization
../data/rfc/rfc3588.txt: and Accounting (AAA) Transport Profile", RFC 3539,
../data/rfc/rfc3588.txt- June 2003.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
../data/rfc/rfc3588.txt- Specifications: ABNF", RFC 2234, November 1997.
../data/rfc/rfc3588.txt-
--
../data/rfc/rfc3588.txt- R., Xu, Y., Campbell, E., Baba, S. and E. Jaques,
../data/rfc/rfc3588.txt- "Criteria for Evaluating AAA Protocols for Network
../data/rfc/rfc3588.txt- Access", RFC 2989, November 2000.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- [ACCMGMT] Aboba, B., Arkko, J. and D. Harrington. "Introduction
../data/rfc/rfc3588.txt: to Accounting Management", RFC 2975, October 2000.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- [CDMA2000] Hiller, T., Walsh, P., Chen, X., Munson, M., Dommety,
../data/rfc/rfc3588.txt- G., Sivalingham, S., Lim, B., McCann, P., Shiino, H.,
../data/rfc/rfc3588.txt- Hirschman, B., Manning, S., Hsu, R., Koo, H., Lipford,
../data/rfc/rfc3588.txt- M., Calhoun, P., Lo, C., Jaques, E., Campbell, E., Xu,
--
../data/rfc/rfc3588.txt- [MIPV4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
../data/rfc/rfc3588.txt- August 2002.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- [MIPREQ] Glass, S., Hiller, T., Jacobs, S. and C. Perkins,
../data/rfc/rfc3588.txt- "Mobile IP Authentication, Authorization, and
../data/rfc/rfc3588.txt: Accounting Requirements", RFC 2977, October 2000.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- [NASNG] Mitton, D. and M. Beadles, "Network Access Server
../data/rfc/rfc3588.txt- Requirements Next Generation (NASREQNG) NAS Model",
../data/rfc/rfc3588.txt- RFC 2881, July 2000.
../data/rfc/rfc3588.txt-
--
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- [PROXYCHAIN] Aboba, B. and J. Vollbrecht, "Proxy Chaining and
../data/rfc/rfc3588.txt- Policy Implementation in Roaming", RFC 2607, June
../data/rfc/rfc3588.txt- 1999.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: [RADACCT] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- [RADEXT] Rigney, C., Willats, W. and P. Calhoun, "RADIUS
../data/rfc/rfc3588.txt- Extensions", RFC 2869, June 2000.
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- [RADIUS] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
--
../data/rfc/rfc3588.txt- The following service template describes the attributes used by
../data/rfc/rfc3588.txt- Diameter servers to advertise themselves. This simplifies the
../data/rfc/rfc3588.txt- process of selecting an appropriate server to communicate with. A
../data/rfc/rfc3588.txt- Diameter client can request specific Diameter servers based on
../data/rfc/rfc3588.txt- characteristics of the Diameter service desired (for example, an AAA
../data/rfc/rfc3588.txt: server to use for accounting.)
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Name of submitter: "Erik Guttman" <Erik.Guttman@sun.com> Language of
../data/rfc/rfc3588.txt- service template: en
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- Security Considerations:
--
../data/rfc/rfc3588.txt-RFC 3588 Diameter Based Protocol September 2003
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt-Appendix C. Duplicate Detection
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: As described in Section 9.4, accounting record duplicate detection is
../data/rfc/rfc3588.txt- based on session identifiers. Duplicates can appear for various
../data/rfc/rfc3588.txt- reasons:
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- - Failover to an alternate server. Where close to real-time
../data/rfc/rfc3588.txt- performance is required, failover thresholds need to be kept low
--
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt- The T flag is used as an indication of an application layer
../data/rfc/rfc3588.txt- retransmission event, e.g., due to failover to an alternate server.
../data/rfc/rfc3588.txt- It is defined only for request messages sent by Diameter clients or
../data/rfc/rfc3588.txt- agents. For instance, after a reboot, a client may not know whether
../data/rfc/rfc3588.txt: it has already tried to send the accounting records in its non-
../data/rfc/rfc3588.txt- volatile memory before the reboot occurred. Diameter servers MAY use
../data/rfc/rfc3588.txt- the T flag as an aid when processing requests and detecting duplicate
../data/rfc/rfc3588.txt- messages. However, servers that do this MUST ensure that duplicates
../data/rfc/rfc3588.txt- are found even when the first transmitted request arrives at the
../data/rfc/rfc3588.txt- server after the retransmitted request. It can be used only in cases
--
../data/rfc/rfc3588.txt- the request is sent again, (e.g., due to a failover to an alternate
../data/rfc/rfc3588.txt- peer, due to a recovered primary peer or due to a client re-sending a
../data/rfc/rfc3588.txt- stored record from non-volatile memory such as after reboot of a
../data/rfc/rfc3588.txt- client or agent).
../data/rfc/rfc3588.txt-
../data/rfc/rfc3588.txt: In some cases the Diameter accounting server can delay the duplicate
../data/rfc/rfc3588.txt: detection and accounting record processing until a post-processing
../data/rfc/rfc3588.txt- phase takes place. At that time records are likely to be sorted
../data/rfc/rfc3588.txt- according to the included User-Name and duplicate elimination is easy
../data/rfc/rfc3588.txt- in this case. In other situations it may be necessary to perform
../data/rfc/rfc3588.txt- real-time duplicate detection, such as when credit limits are imposed
../data/rfc/rfc3588.txt- or real-time fraud detection is desired.
--
../data/rfc/rfc3588.txt- increases as the failover interval is decreased. In order to be
../data/rfc/rfc3588.txt- able to detect out of order duplicates, the Diameter server should
../data/rfc/rfc3588.txt- use backward and forward time windows when performing duplicate
../data/rfc/rfc3588.txt- checking for the T flag marked request. For example, in order to
../data/rfc/rfc3588.txt- allow time for the original record to exit the network and be
../data/rfc/rfc3588.txt: recorded by the accounting server, the Diameter server can delay
../data/rfc/rfc3588.txt- processing records with the T flag set until a time period
../data/rfc/rfc3588.txt- TIME_WAIT + RECORD_PROCESSING_TIME has elapsed after the closing
../data/rfc/rfc3588.txt- of the original transport connection. After this time period has
../data/rfc/rfc3588.txt- expired, then it may check the T flag marked records against the
../data/rfc/rfc3588.txt- database with relative assurance that the original records, if
--
../data/rfc/rfc4671.txt-Request for Comments: 4671 Enterasys Networks
../data/rfc/rfc4671.txt-Obsoletes: 2621 August 2006
../data/rfc/rfc4671.txt-Category: Informational
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt: RADIUS Accounting Server MIB for IPv6
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-Status of This Memo
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- This memo provides information for the Internet community. It does
../data/rfc/rfc4671.txt- not specify an Internet standard of any kind. Distribution of this
--
../data/rfc/rfc4671.txt- Copyright (C) The Internet Society (2006).
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-Abstract
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- This memo defines a set of extensions that instrument RADIUS
../data/rfc/rfc4671.txt: accounting server functions. These extensions represent a portion of
../data/rfc/rfc4671.txt- the Management Information Base (MIB) for use with network management
../data/rfc/rfc4671.txt- protocols in the Internet community. Using these extensions,
../data/rfc/rfc4671.txt: IP-based management stations can manage RADIUS accounting servers.
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- This memo obsoletes RFC 2621 by deprecating the MIB table containing
../data/rfc/rfc4671.txt- IPv4-only address formats and defining a new table to add support for
../data/rfc/rfc4671.txt- version-neutral IP address formats. The remaining MIB objects from
../data/rfc/rfc4671.txt- RFC 2621 are carried forward into this document. This memo also adds
--
../data/rfc/rfc4671.txt-1. Introduction
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- This memo defines a portion of the Management Information Base (MIB)
../data/rfc/rfc4671.txt- for use with network management protocols in the Internet community.
../data/rfc/rfc4671.txt- The objects defined within this memo relate to the Remote
../data/rfc/rfc4671.txt: Authentication Dial-In User Service (RADIUS) Accounting Server as
../data/rfc/rfc4671.txt- defined in RFC 2866 [RFC2866].
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-2. Terminology
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
--
../data/rfc/rfc4671.txt- RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
../data/rfc/rfc4671.txt- [RFC2580].
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-4. Scope of Changes
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt: This document obsoletes RFC 2621 [RFC2621], RADIUS Accounting Server
../data/rfc/rfc4671.txt- MIB, by deprecating the radiusAccClientTable table and adding a new
../data/rfc/rfc4671.txt- table, radiusAccClientExtTable, containing
../data/rfc/rfc4671.txt- radiusAccClientInetAddressType and radiusAccClientInetAddress. The
../data/rfc/rfc4671.txt- purpose of these added MIB objects is to support version-neutral IP
../data/rfc/rfc4671.txt- addressing formats. The existing table containing
--
../data/rfc/rfc4671.txt- changed to "deprecated". The other approach, of having multiple
../data/rfc/rfc4671.txt- similar tables for different IP versions, is strongly discouraged.'
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-5. Structure of the MIB Module
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt: The RADIUS accounting protocol, described in RFC 2866 [RFC2866],
../data/rfc/rfc4671.txt- distinguishes between the client function and the server function.
../data/rfc/rfc4671.txt: In RADIUS accounting, clients send Accounting-Requests, and servers
../data/rfc/rfc4671.txt: reply with Accounting-Responses. Typically, Network Access Server
../data/rfc/rfc4671.txt- (NAS) devices implement the client function, and thus would be
../data/rfc/rfc4671.txt: expected to implement the RADIUS accounting client MIB, while RADIUS
../data/rfc/rfc4671.txt: accounting servers implement the server function, and thus would be
../data/rfc/rfc4671.txt: expected to implement the RADIUS accounting server MIB.
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt: However, it is possible for a RADIUS accounting entity to perform
../data/rfc/rfc4671.txt- both client and server functions. For example, a RADIUS proxy may
../data/rfc/rfc4671.txt: act as a server to one or more RADIUS accounting clients, while
../data/rfc/rfc4671.txt: simultaneously acting as an accounting client to one or more
../data/rfc/rfc4671.txt: accounting servers. In such situations, it is expected that RADIUS
../data/rfc/rfc4671.txt- entities combining client and server functionality will support both
../data/rfc/rfc4671.txt- the client and server MIBs. The server MIB is defined in this
../data/rfc/rfc4671.txt- document, and the client MIB is defined in [RFC4670].
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- This MIB module contains thirteen scalars as well as a single table,
../data/rfc/rfc4671.txt: the RADIUS Accounting Client Table, which contains one row for each
../data/rfc/rfc4671.txt: RADIUS accounting client with which the server shares a secret. Each
../data/rfc/rfc4671.txt: entry in the RADIUS Accounting Client Table includes twelve columns
../data/rfc/rfc4671.txt: presenting a view of the activity of the RADIUS accounting server.
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- This MIB imports from [RFC2578], [RFC2580], [RFC3411], and [RFC4001].
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-
--
../data/rfc/rfc4671.txt- accurately be represented in both the new table and the
../data/rfc/rfc4671.txt- deprecated table.
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- Managed entities SHOULD NOT instantiate row entries in the deprecated
../data/rfc/rfc4671.txt- table, containing IPv4-only address objects, when the RADIUS
../data/rfc/rfc4671.txt: accounting client address represented in such a table row is not an
../data/rfc/rfc4671.txt- IPv4 address. Managed entities SHOULD NOT return inaccurate values
../data/rfc/rfc4671.txt- of IP address or SNMP object access errors for IPv4-only address
../data/rfc/rfc4671.txt- objects in otherwise populated tables. When row entries exist in
../data/rfc/rfc4671.txt- both the deprecated IPv4-only table and the new IP-version-neutral
../data/rfc/rfc4671.txt: table that describe the same RADIUS accounting client, the row
../data/rfc/rfc4671.txt- indexes SHOULD be the same for the corresponding rows in each table,
../data/rfc/rfc4671.txt- to facilitate correlation of these related rows by management
../data/rfc/rfc4671.txt- applications.
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-7. Definitions
--
../data/rfc/rfc4671.txt- Phone: +1 425 936 6605
../data/rfc/rfc4671.txt- EMail: bernarda@microsoft.com"
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt- "The MIB module for entities implementing the server
../data/rfc/rfc4671.txt- side of the Remote Authentication Dial-In User
../data/rfc/rfc4671.txt: Service (RADIUS) accounting protocol. Copyright (C)
../data/rfc/rfc4671.txt- The Internet Society (2006). This version of this
../data/rfc/rfc4671.txt- MIB module is part of RFC 4671; see the RFC itself
../data/rfc/rfc4671.txt- for full legal notices."
../data/rfc/rfc4671.txt- REVISION "200608210000Z" -- 21 August 2006
../data/rfc/rfc4671.txt- DESCRIPTION
--
../data/rfc/rfc4671.txt- and defining a new table to add support for version-
../data/rfc/rfc4671.txt- neutral IP address formats. The remaining MIB objects
../data/rfc/rfc4671.txt- from RFC 2621 are carried forward into this version."
../data/rfc/rfc4671.txt- REVISION "199906110000Z" -- 11 Jun 1999
../data/rfc/rfc4671.txt- DESCRIPTION "Initial version as published in RFC 2621."
../data/rfc/rfc4671.txt: ::= { radiusAccounting 1 }
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- radiusMIB OBJECT-IDENTITY
../data/rfc/rfc4671.txt- STATUS current
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt- "The OID assigned to RADIUS MIB work by the IANA."
../data/rfc/rfc4671.txt- ::= { mib-2 67 }
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt: radiusAccounting OBJECT IDENTIFIER ::= {radiusMIB 2}
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- radiusAccServMIBObjects OBJECT IDENTIFIER
../data/rfc/rfc4671.txt- ::= { radiusAccServMIB 1 }
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- radiusAccServ OBJECT IDENTIFIER
--
../data/rfc/rfc4671.txt- SYNTAX SnmpAdminString
../data/rfc/rfc4671.txt- MAX-ACCESS read-only
../data/rfc/rfc4671.txt- STATUS current
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt- "The implementation identification string for the
../data/rfc/rfc4671.txt: RADIUS accounting server software in use on the
../data/rfc/rfc4671.txt- system, for example, 'FNS-2.1'."
../data/rfc/rfc4671.txt- ::= {radiusAccServ 1}
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- radiusAccServUpTime OBJECT-TYPE
../data/rfc/rfc4671.txt- SYNTAX TimeTicks
--
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-RFC 4671 RADIUS Acct Server MIB (IPv6) August 2006
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- "The number of packets received on the
../data/rfc/rfc4671.txt: accounting port."
../data/rfc/rfc4671.txt- REFERENCE "RFC 2866 section 4.1"
../data/rfc/rfc4671.txt- ::= { radiusAccServ 5 }
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- radiusAccServTotalInvalidRequests OBJECT-TYPE
../data/rfc/rfc4671.txt- SYNTAX Counter32
../data/rfc/rfc4671.txt- UNITS "packets"
../data/rfc/rfc4671.txt- MAX-ACCESS read-only
../data/rfc/rfc4671.txt- STATUS current
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt: "The number of RADIUS Accounting-Request packets
../data/rfc/rfc4671.txt- received from unknown addresses."
../data/rfc/rfc4671.txt- REFERENCE "RFC 2866 sections 2, 4.1"
../data/rfc/rfc4671.txt- ::= { radiusAccServ 6 }
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- radiusAccServTotalDupRequests OBJECT-TYPE
../data/rfc/rfc4671.txt- SYNTAX Counter32
../data/rfc/rfc4671.txt- UNITS "packets"
../data/rfc/rfc4671.txt- MAX-ACCESS read-only
../data/rfc/rfc4671.txt- STATUS current
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt: "The number of duplicate RADIUS Accounting-Request
../data/rfc/rfc4671.txt- packets received."
../data/rfc/rfc4671.txt- REFERENCE "RFC 2866 section 4.1"
../data/rfc/rfc4671.txt- ::= { radiusAccServ 7 }
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- radiusAccServTotalResponses OBJECT-TYPE
../data/rfc/rfc4671.txt- SYNTAX Counter32
../data/rfc/rfc4671.txt- UNITS "packets"
../data/rfc/rfc4671.txt- MAX-ACCESS read-only
../data/rfc/rfc4671.txt- STATUS current
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt: "The number of RADIUS Accounting-Response packets
../data/rfc/rfc4671.txt- sent."
../data/rfc/rfc4671.txt- REFERENCE "RFC 2866 section 4.2"
../data/rfc/rfc4671.txt- ::= { radiusAccServ 8 }
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- radiusAccServTotalMalformedRequests OBJECT-TYPE
../data/rfc/rfc4671.txt- SYNTAX Counter32
../data/rfc/rfc4671.txt- UNITS "packets"
../data/rfc/rfc4671.txt- MAX-ACCESS read-only
../data/rfc/rfc4671.txt- STATUS current
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt: "The number of malformed RADIUS Accounting-Request
../data/rfc/rfc4671.txt- packets received. Bad authenticators or unknown
../data/rfc/rfc4671.txt- types are not included as malformed Access-Requests."
../data/rfc/rfc4671.txt- REFERENCE "RFC 2866 section 3"
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-
--
../data/rfc/rfc4671.txt- SYNTAX Counter32
../data/rfc/rfc4671.txt- UNITS "packets"
../data/rfc/rfc4671.txt- MAX-ACCESS read-only
../data/rfc/rfc4671.txt- STATUS current
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt: "The number of RADIUS Accounting-Request packets
../data/rfc/rfc4671.txt- that contained an invalid authenticator."
../data/rfc/rfc4671.txt- REFERENCE "RFC 2866 section 3"
../data/rfc/rfc4671.txt- ::= { radiusAccServ 10 }
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- radiusAccServTotalPacketsDropped OBJECT-TYPE
--
../data/rfc/rfc4671.txt- SYNTAX Counter32
../data/rfc/rfc4671.txt- UNITS "packets"
../data/rfc/rfc4671.txt- MAX-ACCESS read-only
../data/rfc/rfc4671.txt- STATUS current
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt: "The number of RADIUS Accounting-Request packets
../data/rfc/rfc4671.txt- that were received and responded to but not
../data/rfc/rfc4671.txt- recorded."
../data/rfc/rfc4671.txt- ::= { radiusAccServ 12 }
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- radiusAccServTotalUnknownTypes OBJECT-TYPE
--
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- SYNTAX SEQUENCE OF RadiusAccClientEntry
../data/rfc/rfc4671.txt- MAX-ACCESS not-accessible
../data/rfc/rfc4671.txt- STATUS deprecated
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt: "The (conceptual) table listing the RADIUS accounting
../data/rfc/rfc4671.txt- clients with which the server shares a secret."
../data/rfc/rfc4671.txt- ::= { radiusAccServ 14 }
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- radiusAccClientEntry OBJECT-TYPE
../data/rfc/rfc4671.txt- SYNTAX RadiusAccClientEntry
../data/rfc/rfc4671.txt- MAX-ACCESS not-accessible
../data/rfc/rfc4671.txt- STATUS deprecated
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt- "An entry (conceptual row) representing a RADIUS
../data/rfc/rfc4671.txt: accounting client with which the server shares a
../data/rfc/rfc4671.txt- secret."
../data/rfc/rfc4671.txt- INDEX { radiusAccClientIndex }
../data/rfc/rfc4671.txt- ::= { radiusAccClientTable 1 }
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- RadiusAccClientEntry ::= SEQUENCE {
--
../data/rfc/rfc4671.txt- radiusAccClientIndex OBJECT-TYPE
../data/rfc/rfc4671.txt- SYNTAX Integer32 (1..2147483647)
../data/rfc/rfc4671.txt- MAX-ACCESS not-accessible
../data/rfc/rfc4671.txt- STATUS deprecated
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt: "A number uniquely identifying each RADIUS accounting
../data/rfc/rfc4671.txt- client with which this server communicates."
../data/rfc/rfc4671.txt- ::= { radiusAccClientEntry 1 }
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- radiusAccClientAddress OBJECT-TYPE
../data/rfc/rfc4671.txt- SYNTAX IpAddress
../data/rfc/rfc4671.txt- MAX-ACCESS read-only
../data/rfc/rfc4671.txt- STATUS deprecated
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt: "The NAS-IP-Address of the RADIUS accounting client
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-Nelson Informational [Page 10]
../data/rfc/rfc4671.txt-
--
../data/rfc/rfc4671.txt- radiusAccClientID OBJECT-TYPE
../data/rfc/rfc4671.txt- SYNTAX SnmpAdminString
../data/rfc/rfc4671.txt- MAX-ACCESS read-only
../data/rfc/rfc4671.txt- STATUS deprecated
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt: "The NAS-Identifier of the RADIUS accounting client
../data/rfc/rfc4671.txt- referred to in this table entry. This is not
../data/rfc/rfc4671.txt- necessarily the same as sysName in MIB II."
../data/rfc/rfc4671.txt- REFERENCE "RFC 2865 section 5.32"
../data/rfc/rfc4671.txt- ::= { radiusAccClientEntry 3 }
../data/rfc/rfc4671.txt-
--
../data/rfc/rfc4671.txt- UNITS "packets"
../data/rfc/rfc4671.txt- MAX-ACCESS read-only
../data/rfc/rfc4671.txt- STATUS deprecated
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt- "The number of packets received from this
../data/rfc/rfc4671.txt: client on the accounting port."
../data/rfc/rfc4671.txt- REFERENCE "RFC 2866 section 4.1"
../data/rfc/rfc4671.txt- ::= { radiusAccClientEntry 5 }
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- radiusAccServDupRequests OBJECT-TYPE
../data/rfc/rfc4671.txt- SYNTAX Counter32
--
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- UNITS "packets"
../data/rfc/rfc4671.txt- MAX-ACCESS read-only
../data/rfc/rfc4671.txt- STATUS deprecated
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt: "The number of duplicate RADIUS Accounting-Request
../data/rfc/rfc4671.txt- packets received from this client."
../data/rfc/rfc4671.txt- REFERENCE "RFC 2866 section 4.1"
../data/rfc/rfc4671.txt- ::= { radiusAccClientEntry 6 }
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- radiusAccServResponses OBJECT-TYPE
../data/rfc/rfc4671.txt- SYNTAX Counter32
../data/rfc/rfc4671.txt- UNITS "packets"
../data/rfc/rfc4671.txt- MAX-ACCESS read-only
../data/rfc/rfc4671.txt- STATUS deprecated
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt: "The number of RADIUS Accounting-Response packets
../data/rfc/rfc4671.txt- sent to this client."
../data/rfc/rfc4671.txt- REFERENCE "RFC 2866 section 4.2"
../data/rfc/rfc4671.txt- ::= { radiusAccClientEntry 7 }
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- radiusAccServBadAuthenticators OBJECT-TYPE
../data/rfc/rfc4671.txt- SYNTAX Counter32
../data/rfc/rfc4671.txt- UNITS "packets"
../data/rfc/rfc4671.txt- MAX-ACCESS read-only
../data/rfc/rfc4671.txt- STATUS deprecated
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt: "The number of RADIUS Accounting-Request packets
../data/rfc/rfc4671.txt- that contained invalid authenticators received
../data/rfc/rfc4671.txt- from this client."
../data/rfc/rfc4671.txt- REFERENCE "RFC 2866 section 3"
../data/rfc/rfc4671.txt- ::= { radiusAccClientEntry 8 }
../data/rfc/rfc4671.txt-
--
../data/rfc/rfc4671.txt- SYNTAX Counter32
../data/rfc/rfc4671.txt- UNITS "packets"
../data/rfc/rfc4671.txt- MAX-ACCESS read-only
../data/rfc/rfc4671.txt- STATUS deprecated
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt: "The number of malformed RADIUS Accounting-Request
../data/rfc/rfc4671.txt- packets that were received from this client.
../data/rfc/rfc4671.txt- Bad authenticators and unknown types
../data/rfc/rfc4671.txt: are not included as malformed Accounting-Requests."
../data/rfc/rfc4671.txt- REFERENCE "RFC 2866 section 3"
../data/rfc/rfc4671.txt- ::= { radiusAccClientEntry 9 }
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- radiusAccServNoRecords OBJECT-TYPE
../data/rfc/rfc4671.txt- SYNTAX Counter32
--
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- MAX-ACCESS read-only
../data/rfc/rfc4671.txt- STATUS deprecated
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt: "The number of RADIUS Accounting-Request packets
../data/rfc/rfc4671.txt- that were received and responded to but not
../data/rfc/rfc4671.txt- recorded."
../data/rfc/rfc4671.txt- ::= { radiusAccClientEntry 10 }
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- radiusAccServUnknownTypes OBJECT-TYPE
--
../data/rfc/rfc4671.txt- radiusAccClientExtTable OBJECT-TYPE
../data/rfc/rfc4671.txt- SYNTAX SEQUENCE OF RadiusAccClientExtEntry
../data/rfc/rfc4671.txt- MAX-ACCESS not-accessible
../data/rfc/rfc4671.txt- STATUS current
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt: "The (conceptual) table listing the RADIUS accounting
../data/rfc/rfc4671.txt- clients with which the server shares a secret."
../data/rfc/rfc4671.txt- ::= { radiusAccServ 15 }
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- radiusAccClientExtEntry OBJECT-TYPE
../data/rfc/rfc4671.txt- SYNTAX RadiusAccClientExtEntry
../data/rfc/rfc4671.txt- MAX-ACCESS not-accessible
../data/rfc/rfc4671.txt- STATUS current
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt- "An entry (conceptual row) representing a RADIUS
../data/rfc/rfc4671.txt: accounting client with which the server shares a
../data/rfc/rfc4671.txt- secret."
../data/rfc/rfc4671.txt- INDEX { radiusAccClientExtIndex }
../data/rfc/rfc4671.txt- ::= { radiusAccClientExtTable 1 }
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- RadiusAccClientExtEntry ::= SEQUENCE {
--
../data/rfc/rfc4671.txt- radiusAccClientExtIndex OBJECT-TYPE
../data/rfc/rfc4671.txt- SYNTAX Integer32 (1..2147483647)
../data/rfc/rfc4671.txt- MAX-ACCESS not-accessible
../data/rfc/rfc4671.txt- STATUS current
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt: "A number uniquely identifying each RADIUS accounting
../data/rfc/rfc4671.txt- client with which this server communicates."
../data/rfc/rfc4671.txt- ::= { radiusAccClientExtEntry 1 }
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- radiusAccClientInetAddressType OBJECT-TYPE
../data/rfc/rfc4671.txt- SYNTAX InetAddressType
--
../data/rfc/rfc4671.txt- radiusAccClientInetAddress OBJECT-TYPE
../data/rfc/rfc4671.txt- SYNTAX InetAddress
../data/rfc/rfc4671.txt- MAX-ACCESS read-only
../data/rfc/rfc4671.txt- STATUS current
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt: "The IP address of the RADIUS accounting
../data/rfc/rfc4671.txt- client referred to in this table entry, using
../data/rfc/rfc4671.txt- the IPv6 address format."
../data/rfc/rfc4671.txt- ::= { radiusAccClientExtEntry 3 }
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- radiusAccClientExtID OBJECT-TYPE
../data/rfc/rfc4671.txt- SYNTAX SnmpAdminString
../data/rfc/rfc4671.txt- MAX-ACCESS read-only
../data/rfc/rfc4671.txt- STATUS current
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt: "The NAS-Identifier of the RADIUS accounting client
../data/rfc/rfc4671.txt- referred to in this table entry. This is not
../data/rfc/rfc4671.txt- necessarily the same as sysName in MIB II."
../data/rfc/rfc4671.txt- REFERENCE "RFC 2865 section 5.32"
../data/rfc/rfc4671.txt- ::= { radiusAccClientExtEntry 4 }
../data/rfc/rfc4671.txt-
--
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt- "The number of incoming packets received from this
../data/rfc/rfc4671.txt- client and silently discarded for a reason other
../data/rfc/rfc4671.txt- than malformed, bad authenticators, or unknown types.
../data/rfc/rfc4671.txt- This counter may experience a discontinuity when the
../data/rfc/rfc4671.txt: RADIUS Accounting Server module within the managed
../data/rfc/rfc4671.txt- entity is reinitialized, as indicated by the current
../data/rfc/rfc4671.txt- value of radiusAccServerCounterDiscontinuity."
../data/rfc/rfc4671.txt- REFERENCE "RFC 2866 section 3"
../data/rfc/rfc4671.txt- ::= { radiusAccClientExtEntry 5 }
../data/rfc/rfc4671.txt-
--
../data/rfc/rfc4671.txt- UNITS "packets"
../data/rfc/rfc4671.txt- MAX-ACCESS read-only
../data/rfc/rfc4671.txt- STATUS current
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt- "The number of packets received from this
../data/rfc/rfc4671.txt: client on the accounting port. This counter
../data/rfc/rfc4671.txt- may experience a discontinuity when the
../data/rfc/rfc4671.txt: RADIUS Accounting Server module within the
../data/rfc/rfc4671.txt- managed entity is reinitialized, as indicated by
../data/rfc/rfc4671.txt- the current value of
../data/rfc/rfc4671.txt- radiusAccServerCounterDiscontinuity."
../data/rfc/rfc4671.txt- REFERENCE "RFC 2866 section 4.1"
../data/rfc/rfc4671.txt- ::= { radiusAccClientExtEntry 6 }
--
../data/rfc/rfc4671.txt- SYNTAX Counter32
../data/rfc/rfc4671.txt- UNITS "packets"
../data/rfc/rfc4671.txt- MAX-ACCESS read-only
../data/rfc/rfc4671.txt- STATUS current
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt: "The number of duplicate RADIUS Accounting-Request
../data/rfc/rfc4671.txt- packets received from this client. This counter
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-Nelson Informational [Page 15]
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-RFC 4671 RADIUS Acct Server MIB (IPv6) August 2006
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- may experience a discontinuity when the RADIUS
../data/rfc/rfc4671.txt: Accounting Server module within the managed
../data/rfc/rfc4671.txt- entity is reinitialized, as indicated by the
../data/rfc/rfc4671.txt- current value of
../data/rfc/rfc4671.txt- radiusAccServerCounterDiscontinuity."
../data/rfc/rfc4671.txt- REFERENCE "RFC 2866 section 4.1"
../data/rfc/rfc4671.txt- ::= { radiusAccClientExtEntry 7 }
--
../data/rfc/rfc4671.txt- SYNTAX Counter32
../data/rfc/rfc4671.txt- UNITS "packets"
../data/rfc/rfc4671.txt- MAX-ACCESS read-only
../data/rfc/rfc4671.txt- STATUS current
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt: "The number of RADIUS Accounting-Response packets
../data/rfc/rfc4671.txt- sent to this client. This counter may experience
../data/rfc/rfc4671.txt: a discontinuity when the RADIUS Accounting Server
../data/rfc/rfc4671.txt- module within the managed entity is reinitialized,
../data/rfc/rfc4671.txt- as indicated by the current value of
../data/rfc/rfc4671.txt- radiusAccServerCounterDiscontinuity."
../data/rfc/rfc4671.txt- REFERENCE "RFC 2866 section 4.2"
../data/rfc/rfc4671.txt- ::= { radiusAccClientExtEntry 8 }
--
../data/rfc/rfc4671.txt- SYNTAX Counter32
../data/rfc/rfc4671.txt- UNITS "packets"
../data/rfc/rfc4671.txt- MAX-ACCESS read-only
../data/rfc/rfc4671.txt- STATUS current
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt: "The number of RADIUS Accounting-Request packets
../data/rfc/rfc4671.txt- that contained invalid authenticators received
../data/rfc/rfc4671.txt- from this client. This counter may experience a
../data/rfc/rfc4671.txt: discontinuity when the RADIUS Accounting Server
../data/rfc/rfc4671.txt- module within the managed entity is reinitialized,
../data/rfc/rfc4671.txt- as indicated by the current value of
../data/rfc/rfc4671.txt- radiusAccServerCounterDiscontinuity."
../data/rfc/rfc4671.txt- REFERENCE "RFC 2866 section 3"
../data/rfc/rfc4671.txt- ::= { radiusAccClientExtEntry 9 }
--
../data/rfc/rfc4671.txt- SYNTAX Counter32
../data/rfc/rfc4671.txt- UNITS "packets"
../data/rfc/rfc4671.txt- MAX-ACCESS read-only
../data/rfc/rfc4671.txt- STATUS current
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt: "The number of malformed RADIUS Accounting-Request
../data/rfc/rfc4671.txt- packets that were received from this client.
../data/rfc/rfc4671.txt- Bad authenticators and unknown types are not
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-Nelson Informational [Page 16]
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-RFC 4671 RADIUS Acct Server MIB (IPv6) August 2006
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt: included as malformed Accounting-Requests. This
../data/rfc/rfc4671.txt- counter may experience a discontinuity when the
../data/rfc/rfc4671.txt: RADIUS Accounting Server module within the managed
../data/rfc/rfc4671.txt- entity is reinitialized, as indicated by the current
../data/rfc/rfc4671.txt- value of radiusAccServerCounterDiscontinuity."
../data/rfc/rfc4671.txt- REFERENCE "RFC 2866 section 3"
../data/rfc/rfc4671.txt- ::= { radiusAccClientExtEntry 10 }
../data/rfc/rfc4671.txt-
--
../data/rfc/rfc4671.txt- SYNTAX Counter32
../data/rfc/rfc4671.txt- UNITS "packets"
../data/rfc/rfc4671.txt- MAX-ACCESS read-only
../data/rfc/rfc4671.txt- STATUS current
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt: "The number of RADIUS Accounting-Request packets
../data/rfc/rfc4671.txt- that were received and responded to but not
../data/rfc/rfc4671.txt- recorded. This counter may experience a
../data/rfc/rfc4671.txt: discontinuity when the RADIUS Accounting Server
../data/rfc/rfc4671.txt- module within the managed entity is reinitialized,
../data/rfc/rfc4671.txt- as indicated by the current value of
../data/rfc/rfc4671.txt- radiusAccServerCounterDiscontinuity."
../data/rfc/rfc4671.txt- ::= { radiusAccClientExtEntry 11 }
../data/rfc/rfc4671.txt-
--
../data/rfc/rfc4671.txt- MAX-ACCESS read-only
../data/rfc/rfc4671.txt- STATUS current
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt- "The number of RADIUS packets of unknown type that
../data/rfc/rfc4671.txt- were received from this client. This counter may
../data/rfc/rfc4671.txt: experience a discontinuity when the RADIUS Accounting
../data/rfc/rfc4671.txt- Server module within the managed entity is
../data/rfc/rfc4671.txt- reinitialized, as indicated by the current value of
../data/rfc/rfc4671.txt- radiusAccServerCounterDiscontinuity."
../data/rfc/rfc4671.txt- REFERENCE "RFC 2866 section 4"
../data/rfc/rfc4671.txt- ::= { radiusAccClientExtEntry 12 }
--
../data/rfc/rfc4671.txt- UNITS "centiseconds"
../data/rfc/rfc4671.txt- MAX-ACCESS read-only
../data/rfc/rfc4671.txt- STATUS current
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt- "The number of centiseconds since the last
../data/rfc/rfc4671.txt: discontinuity in the RADIUS Accounting Server
../data/rfc/rfc4671.txt- counters. A discontinuity may be the result of
../data/rfc/rfc4671.txt: a reinitialization of the RADIUS Accounting Server
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-Nelson Informational [Page 17]
../data/rfc/rfc4671.txt-
--
../data/rfc/rfc4671.txt- -- compliance statements
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- radiusAccServMIBCompliance MODULE-COMPLIANCE
../data/rfc/rfc4671.txt- STATUS deprecated
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt: "The compliance statement for accounting servers
../data/rfc/rfc4671.txt: implementing the RADIUS Accounting Server MIB.
../data/rfc/rfc4671.txt- Implementation of this module is for IPv4-only
../data/rfc/rfc4671.txt- entities, or for backwards compatibility use with
../data/rfc/rfc4671.txt- entities that support both IPv4 and IPv6."
../data/rfc/rfc4671.txt- MODULE -- this module
../data/rfc/rfc4671.txt- MANDATORY-GROUPS { radiusAccServMIBGroup }
--
../data/rfc/rfc4671.txt- ::= { radiusAccServMIBCompliances 1 }
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- radiusAccServExtMIBCompliance MODULE-COMPLIANCE
../data/rfc/rfc4671.txt- STATUS current
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt: "The compliance statement for accounting
../data/rfc/rfc4671.txt: servers implementing the RADIUS Accounting
../data/rfc/rfc4671.txt- Server IPv6 Extensions MIB. Implementation of
../data/rfc/rfc4671.txt- this module is for entities that support IPv6,
../data/rfc/rfc4671.txt- or support IPv4 and IPv6."
../data/rfc/rfc4671.txt- MODULE -- this module
../data/rfc/rfc4671.txt- MANDATORY-GROUPS { radiusAccServExtMIBGroup }
--
../data/rfc/rfc4671.txt- radiusAccServUnknownTypes
../data/rfc/rfc4671.txt- }
../data/rfc/rfc4671.txt- STATUS deprecated
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt- "The collection of objects providing management of
../data/rfc/rfc4671.txt: a RADIUS Accounting Server."
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-Nelson Informational [Page 19]
../data/rfc/rfc4671.txt-
--
../data/rfc/rfc4671.txt- radiusAccServerCounterDiscontinuity
../data/rfc/rfc4671.txt- }
../data/rfc/rfc4671.txt- STATUS current
../data/rfc/rfc4671.txt- DESCRIPTION
../data/rfc/rfc4671.txt- "The collection of objects providing management of
../data/rfc/rfc4671.txt: a RADIUS Accounting Server."
../data/rfc/rfc4671.txt- ::= { radiusAccServMIBGroups 2 }
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- END
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-8. Security Considerations
--
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- There are a number of managed objects in this MIB that may contain
../data/rfc/rfc4671.txt- sensitive information. These are:
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- radiusAccClientIPAddress
../data/rfc/rfc4671.txt: This can be used to determine the address of the RADIUS accounting
../data/rfc/rfc4671.txt- client with which the server is communicating. This information
../data/rfc/rfc4671.txt: could be useful in mounting an attack on the accounting client.
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- radiusAccClientInetAddress
../data/rfc/rfc4671.txt: This can be used to determine the address of the RADIUS accounting
../data/rfc/rfc4671.txt- client with which the server is communicating. This information
../data/rfc/rfc4671.txt: could be useful in mounting an attack on the accounting client.
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- It is thus important to control even GET access to these objects and
../data/rfc/rfc4671.txt- possibly to even encrypt the values of these object when sending them
../data/rfc/rfc4671.txt- over the network via SNMP. Not all versions of SNMP provide features
../data/rfc/rfc4671.txt- for such a secure environment.
--
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
../data/rfc/rfc4671.txt- "Conformance Statements for SMIv2", STD 58, RFC 2580,
../data/rfc/rfc4671.txt- April 1999.
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
../data/rfc/rfc4671.txt- Architecture for Describing Simple Network Management
../data/rfc/rfc4671.txt- Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
../data/rfc/rfc4671.txt- December 2002.
--
../data/rfc/rfc4671.txt- Schoenwaelder, "Textual Conventions for Internet Network
../data/rfc/rfc4671.txt- Addresses", RFC 4001, February 2005.
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-9.2. Informative References
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt: [RFC2621] Zorn, G. and B. Aboba, "RADIUS Accounting Server MIB",
../data/rfc/rfc4671.txt- RFC 2621, June 1999.
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
../data/rfc/rfc4671.txt- "Remote Authentication Dial In User Service (RADIUS)",
../data/rfc/rfc4671.txt- RFC 2865, June 2000.
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt- [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
../data/rfc/rfc4671.txt- "Introduction and Applicability Statements for Internet-
../data/rfc/rfc4671.txt- Standard Management Framework", RFC 3410, December 2002.
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt: [RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC
../data/rfc/rfc4671.txt- 4670, August 2006.
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-
../data/rfc/rfc4671.txt-
--
../data/rfc/rfc5578.txt- session credit calculations. The Credit Scale Factor TLV is optional
../data/rfc/rfc5578.txt- with the PADR and PADS packets. Once the session is established with
../data/rfc/rfc5578.txt- specified scale factors, the scale factors are set for the entire
../data/rfc/rfc5578.txt- session. The scale factor value represents the units that the local
../data/rfc/rfc5578.txt- node grants to the remote node. The remote node is responsible for
../data/rfc/rfc5578.txt: maintaining the credit accounting relative to the data flow back to
../data/rfc/rfc5578.txt- the local node.
../data/rfc/rfc5578.txt-
../data/rfc/rfc5578.txt- The Credit Scale Factor TLV can be used to change from the default
../data/rfc/rfc5578.txt- 64-byte credit unit during the PADR-PADS exchange. The credit scale
../data/rfc/rfc5578.txt- factor value can range from 1 byte to 65535 bytes. A zero value is
--
../data/rfc/rfc5578.txt-4. Credit Flow Considerations
../data/rfc/rfc5578.txt-
../data/rfc/rfc5578.txt- For a given session, credit grants exchanged in the Discovery Stage,
../data/rfc/rfc5578.txt- PADG-PADC, are referred to as out-of-band. Credit grants exchanged
../data/rfc/rfc5578.txt- in the PPP Session Stage are referred to as in-band. Credit
../data/rfc/rfc5578.txt: accounting is only applied to the packets transmitted in the PPP
../data/rfc/rfc5578.txt- Session Stage.
../data/rfc/rfc5578.txt-
../data/rfc/rfc5578.txt- Out-of-band credit management is handled by periodic exchange of the
../data/rfc/rfc5578.txt- PPPoE Active Discovery Session-Grant (PADG) and PPPoE Active
../data/rfc/rfc5578.txt- Discovery Credit Response (PADC) packets.
--
../data/rfc/rfc2903.txt-
../data/rfc/rfc2903.txt- Copyright (C) The Internet Society (2000). All Rights Reserved.
../data/rfc/rfc2903.txt-
../data/rfc/rfc2903.txt-Abstract
../data/rfc/rfc2903.txt-
../data/rfc/rfc2903.txt: This memo proposes an Authentication, Authorization, Accounting (AAA)
../data/rfc/rfc2903.txt- architecture that would incorporate a generic AAA server along with
../data/rfc/rfc2903.txt- an application interface to a set of Application Specific Modules
../data/rfc/rfc2903.txt- that could perform application specific AAA functions. A separation
../data/rfc/rfc2903.txt- of AAA functions required in a multi-domain environment is then
../data/rfc/rfc2903.txt- proposed using a layered protocol abstraction. The long term goal is
--
../data/rfc/rfc2903.txt- generic AAA server and a set of one or more Application Specific
../data/rfc/rfc2903.txt- Modules (ASMs) which can carry out the unique functionality required
../data/rfc/rfc2903.txt- by each application.
../data/rfc/rfc2903.txt-
../data/rfc/rfc2903.txt- Since the data required by each application for authentication,
../data/rfc/rfc2903.txt: authorization, or accounting may have unique structure, the standard
../data/rfc/rfc2903.txt- AAA protocol should allow the encapsulation of opaque units of
../data/rfc/rfc2903.txt- Application Specific Information (ASI). These units would begin with
../data/rfc/rfc2903.txt- a standard header to allow them to be forwarded by the generic
../data/rfc/rfc2903.txt- infrastructure. When delivered to the final destination, an ASI unit
../data/rfc/rfc2903.txt- would be passed by a generic AAA server across its program interface
--
../data/rfc/rfc2903.txt- Application Specific Modules by applying security techniques such as
../data/rfc/rfc2903.txt- public key encryption or digital signatures to the Application
../data/rfc/rfc2903.txt- Specific Information units individually, so that different
../data/rfc/rfc2903.txt- stakeholders in the AAA server network can protect selected
../data/rfc/rfc2903.txt- information units from being deciphered or altered by other
../data/rfc/rfc2903.txt: stakeholders in an authentication, authorization, or accounting
../data/rfc/rfc2903.txt- chain.
../data/rfc/rfc2903.txt-
../data/rfc/rfc2903.txt-2. Generic AAA Architecture
../data/rfc/rfc2903.txt-
../data/rfc/rfc2903.txt- For the long term we envision a generic AAA server which is capable
../data/rfc/rfc2903.txt- of authenticating users, handling authorization requests, and
../data/rfc/rfc2903.txt: collecting accounting data. For a service provider, such a generic
../data/rfc/rfc2903.txt- AAA server would be interfaced to an application specific module
../data/rfc/rfc2903.txt- which manages the resource for which authorization is required.
../data/rfc/rfc2903.txt- Generic AAA components would also be deployed in other administrative
../data/rfc/rfc2903.txt- domains performing authorization functions.
../data/rfc/rfc2903.txt-
--
../data/rfc/rfc2903.txt-
../data/rfc/rfc2903.txt- In each of these cases, the AAA-TSM service layer must synchronize
../data/rfc/rfc2903.txt- the Authorized Session's distributed state across all of those AAA
../data/rfc/rfc2903.txt- Servers which are implementing that specific Authorized Session.
../data/rfc/rfc2903.txt-
../data/rfc/rfc2903.txt: Accounting -- Generate any relevant accounting information regarding
../data/rfc/rfc2903.txt- the authorization decision and the associated Authorized Session
../data/rfc/rfc2903.txt- (if any) that represents the ongoing consumption of those services
../data/rfc/rfc2903.txt- or resources.
../data/rfc/rfc2903.txt-
../data/rfc/rfc2903.txt- The peer AAA servers and their AAA-TSM end points exchange AAA-TSM
--
../data/rfc/rfc477.txt- and back in again, possibly from another site.
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt- The sequence of events involved in using RJS are as follows. First,
../data/rfc/rfc477.txt- the user logs in, specifying a user name, password, and account
../data/rfc/rfc477.txt- number. In addition to indicating how subsequent use of RJS is to be
../data/rfc/rfc477.txt: billed, this accounting information identifies the owner of a
../data/rfc/rfc477.txt- particular RJE terminal. That is, the association between user name
../data/rfc/rfc477.txt- and HASP virtual RJE terminal is unique, and only one individual is
../data/rfc/rfc477.txt- allowed logged in under a given user name at a time.
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt- At present, billing within RJS is not implemented, and therefore the
--
../data/rfc/rfc477.txt- In order to simplify specification of job parameters, RJS maintains a
../data/rfc/rfc477.txt- set of accumulators for these parameters. Each accumulator is
../data/rfc/rfc477.txt- initially empty, and may have its contents set or referred to by
../data/rfc/rfc477.txt- various commands. The following parameter accumulators are
../data/rfc/rfc477.txt- maintained for each user (user name, password, and account together
../data/rfc/rfc477.txt: are termed accounting parameters): login accounting parameter (those
../data/rfc/rfc477.txt- specified either in the LOGIN or the USER, PASS, and ACCT commands),
../data/rfc/rfc477.txt: source pathname, print pathname, punch pathname, source accounting
../data/rfc/rfc477.txt: parameter, print accounting parameter, and punch accounting
../data/rfc/rfc477.txt- parameter. In addition, associated with each job are the parameters
../data/rfc/rfc477.txt- source, print, and punch pathname, and source, print, and punch
../data/rfc/rfc477.txt: accounting parameters.
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt- When the TELNET connections are first opened, RJS sends the user a
../data/rfc/rfc477.txt- herald message of the form '300 UCSB RJS (VER. <date>) TTY
../data/rfc/rfc477.txt- <integer>.', where <date> identifies the current version of RJS, and
../data/rfc/rfc477.txt- <integer> identifies the user's terminal in the sense that each
--
../data/rfc/rfc477.txt- response '504 LOGIN PLEASE.' is displayed if the user is not logged
../data/rfc/rfc477.txt- in.
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt- 'USER' ['='] <user name> <CA>
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt: Specifies the user's user name for accounting purposes, initiates
../data/rfc/rfc477.txt- login, and initializes the source, print, and punch user name
../data/rfc/rfc477.txt- accumulators to <user name>. To complete login, this command must be
../data/rfc/rfc477.txt- followed by a successful PASS command. The only other command
../data/rfc/rfc477.txt- allowed before the user is logged in is BYE. The response to a
../data/rfc/rfc477.txt- syntactically valid USER command is always '330 ENTER PASSWORD'
--
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt- The remaining commands require the user to be logged in.
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt- 'REINIT' <CA>
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt: Resets to empty the source, print, and punch accounting parameter,
../data/rfc/rfc477.txt: the source, print, and punch pathname, and the login accounting
../data/rfc/rfc477.txt- parameter accumulators. The response to a REINIT command is always
../data/rfc/rfc477.txt- '204 OK'.
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt- ('INUSER' _ 'INID') ['='] <user name> <CA>
../data/rfc/rfc477.txt-
--
../data/rfc/rfc477.txt- produced
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt- 'INPUT' <CA>
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt- Creates a job, stores with it the contents of the source, print, and
../data/rfc/rfc477.txt: punch accounting parameter and pathname accumulators, and places it
../data/rfc/rfc477.txt- in a queue within RJS of jobs owned by the user awaiting source file
../data/rfc/rfc477.txt- transfer. When it becomes the first or only job in this queue, the
../data/rfc/rfc477.txt- retrieval of its source file is initiated. A job identifier
../data/rfc/rfc477.txt- ('jobid') is assigned to the job and displayed to the user. The
../data/rfc/rfc477.txt- contents of the source and print pathname accumulators must have been
--
../data/rfc/rfc477.txt- 'STATUS' <jobid> <CA>
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt- Causes the status of the job known to RJS as <jobid> to be displayed.
../data/rfc/rfc477.txt- Included in this display are in which stage of RJS processing the job
../data/rfc/rfc477.txt- is ('BEING READ', 'IN EXECUTION', 'BEING PRINTED', 'BEING PUNCHED',
../data/rfc/rfc477.txt: or 'HAS COMPLETED'), the pathname information (accounting parameters,
../data/rfc/rfc477.txt- host name, socket number, attributes, disposition, and filename) for
../data/rfc/rfc477.txt- those files (source, print and punch) that have been supplied for the
../data/rfc/rfc477.txt- job, and if the job has failed at some stage of RJS processing, an
../data/rfc/rfc477.txt- explanation of the failure. The possible responses are '464 JOB
../data/rfc/rfc477.txt- <jobid> NOT FOUND.', and a line with reply code 161 followed by zero
--
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt- 'LOGIN' <user name> <password> <account> <CA>
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt- Specifies the UCSB Computer Center user name and account to which the
../data/rfc/rfc477.txt- user's use Of RJS is to be billed, logs the user in, and sets the
../data/rfc/rfc477.txt: source, print, and punch accounting parameter accumulators to <user
../data/rfc/rfc477.txt- name>, <password> and <account>. This command is valid only if the
../data/rfc/rfc477.txt- user is not logged in, and has the same replies as the standard
../data/rfc/rfc477.txt- syntax 'PASS' command.
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt- 'DISCONNECT' <CA>
--
../data/rfc/rfc477.txt- The remaining commands require the user to be logged in.
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt- 'LOG0UT' <CA>
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt- Logs the user out and terminates billing of subsequent activity over
../data/rfc/rfc477.txt: the TELNET connection to the previously effective accounting
../data/rfc/rfc477.txt- parameters, and performs the effective action of the REINITIALIZE
../data/rfc/rfc477.txt- command. LOGOUT does not close the TELNET connection, nor does it
../data/rfc/rfc477.txt- affect any file transfers in progress for jobs owned by the user.
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt- 'REINITIALIZE' <CA>
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt- Resets to empty the following accumulators: source, print and punch
../data/rfc/rfc477.txt: accounting parameter, source, print and punch pathname, and login
../data/rfc/rfc477.txt: accounting parameter.
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt: 'ACCOUNTING' <account parms> <CA>
../data/rfc/rfc477.txt- <account parms> = '(' ',' ',' <a> ')'
../data/rfc/rfc477.txt- = <user name> _ <null>
../data/rfc/rfc477.txt- = <password> _ <null>
../data/rfc/rfc477.txt- <a> = <account> _ <null>
../data/rfc/rfc477.txt-
--
../data/rfc/rfc477.txt-Krilanovich [Page 11]
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt-RFC 477 Remote Job Service at UCSB 23 May 1973
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt: Sets the source, print and punch accounting parameters to <account
../data/rfc/rfc477.txt- parms>. Specification of <null> for any of , , or <a>
../data/rfc/rfc477.txt- indicates use of the contents of the corresponding login accumulator.
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt- 'SOURCE' <account parms> <CA>
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt: Set the source accounting parameter accumulators to <account parms>.
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt- 'PRINT' <account parms> <CA>
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt: Sets the print accounting parameter accumulators to <account parms>.
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt- 'PUNCH' <account parms> <CA>
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt: Sets the punch accounting parameter accumulators to <account parms>.
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt- 'SOURCE' <jobid> (<account parms> _ <null>) <pathname> <CA>
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt- Sets the source pathname of job <jobid> to <pathname>, and the source
../data/rfc/rfc477.txt: accounting parameters to <account parms>, if specified, or otherwise
../data/rfc/rfc477.txt: to the contents of the source accounting parameter accumulators. If
../data/rfc/rfc477.txt- job <jobid> already exists and its source pathname has not been
../data/rfc/rfc477.txt- specified, the new pathname is stored; if it has been specified, it
../data/rfc/rfc477.txt- is changed unless source file retrieval has already begun. If the
../data/rfc/rfc477.txt- job does not already exist, a new job is created and the pathname
../data/rfc/rfc477.txt- stored. Restrictions are that if a job with a given <jobid> has
--
../data/rfc/rfc477.txt- READ.'
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt- 'PRINT <jobid> (<account parms> _ <null>) <disp> <CA>
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt- Sets the print pathname of job <jobid> to <disp>, and the print
../data/rfc/rfc477.txt: accounting parameters to <account parms> if specified, or otherwise
../data/rfc/rfc477.txt: to the contents of the print accounting parameter accumulators. The
../data/rfc/rfc477.txt- PRINT command either creates a new job or modifies an existing one,
../data/rfc/rfc477.txt- as explained under SOURCE, and has the same restrictions and error
../data/rfc/rfc477.txt- messages listed for the SOURCE command, after making the obvious
../data/rfc/rfc477.txt- substitution of 'PRINTED' for 'READ'. The PRINT command is valid
../data/rfc/rfc477.txt- only before print file transfer begins.
--
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt- 'PUNCH' <jobid> (<account parms> _ <null>) <disp> <CA>
../data/rfc/rfc477.txt-
../data/rfc/rfc477.txt- Sets the punch pathname of job <jobid> to <disp>, and the punch
../data/rfc/rfc477.txt: accounting parameters to <account parms> if specified, or otherwise
../data/rfc/rfc477.txt: to the contents of the punch accounting parameter accumulators. The
../data/rfc/rfc477.txt- PUNCH command either creates a new job or modifies an existing one,
../data/rfc/rfc477.txt- like the SOURCE and PRINT commands, and has the same restrictions and
../data/rfc/rfc477.txt- error messages listed for the SOURCE command, after making the
../data/rfc/rfc477.txt- substitution of 'PUNCHED' for 'READ'. The PUNCH command is valid
../data/rfc/rfc477.txt- only before punch file transfer begins.
--
../data/rfc/rfc2868.txt- Description
../data/rfc/rfc2868.txt-
../data/rfc/rfc2868.txt- This Attribute indicates the tunneling protocol(s) to be used (in
../data/rfc/rfc2868.txt- the case of a tunnel initiator) or the the tunneling protocol in
../data/rfc/rfc2868.txt- use (in the case of a tunnel terminator). It MAY be included in
../data/rfc/rfc2868.txt: Access-Request, Access-Accept and Accounting-Request packets. If
../data/rfc/rfc2868.txt- the Tunnel-Type Attribute is present in an Access-Request packet
../data/rfc/rfc2868.txt- sent from a tunnel initiator, it SHOULD be taken as a hint to the
../data/rfc/rfc2868.txt- RADIUS server as to the tunnelling protocols supported by the
../data/rfc/rfc2868.txt- tunnel end-point; the RADIUS server MAY ignore the hint, however.
../data/rfc/rfc2868.txt- A tunnel initiator is not required to implement any of these
--
../data/rfc/rfc2868.txt- tunnel. It MAY be included in both Access-Request and Access-
../data/rfc/rfc2868.txt- Accept packets to indicate the address from which a new tunnel is
../data/rfc/rfc2868.txt- to be initiated. If the Tunnel-Client-Endpoint Attribute is
../data/rfc/rfc2868.txt- included in an Access-Request packet, the RADIUS server should
../data/rfc/rfc2868.txt- take the value as a hint; the server is not obligated to honor the
../data/rfc/rfc2868.txt: hint, however. This Attribute SHOULD be included in Accounting-
../data/rfc/rfc2868.txt- Request packets which contain Acct-Status-Type attributes with
../data/rfc/rfc2868.txt- values of either Start or Stop, in which case it indicates the
../data/rfc/rfc2868.txt- address from which the tunnel was initiated. This Attribute,
../data/rfc/rfc2868.txt- along with the Tunnel-Server-Endpoint and Acct-Tunnel-Connection-
../data/rfc/rfc2868.txt- ID attributes, may be used to provide a globally unique means to
../data/rfc/rfc2868.txt: identify a tunnel for accounting and auditing purposes.
../data/rfc/rfc2868.txt-
../data/rfc/rfc2868.txt- A summary of the Tunnel-Client-Endpoint Attribute format is shown
../data/rfc/rfc2868.txt- below. The fields are transmitted from left to right.
../data/rfc/rfc2868.txt-
../data/rfc/rfc2868.txt- 0 1 2 3
--
../data/rfc/rfc2868.txt-
../data/rfc/rfc2868.txt- This Attribute indicates the address of the server end of the
../data/rfc/rfc2868.txt- tunnel. The Tunnel-Server-Endpoint Attribute MAY be included (as
../data/rfc/rfc2868.txt- a hint to the RADIUS server) in the Access-Request packet and MUST
../data/rfc/rfc2868.txt- be included in the Access-Accept packet if the initiation of a
../data/rfc/rfc2868.txt: tunnel is desired. It SHOULD be included in Accounting-Request
../data/rfc/rfc2868.txt- packets which contain Acct-Status-Type attributes with values of
../data/rfc/rfc2868.txt- either Start or Stop and which pertain to a tunneled session.
../data/rfc/rfc2868.txt- This Attribute, along with the Tunnel-Client-Endpoint and Acct-
../data/rfc/rfc2868.txt- Tunnel-Connection-ID Attributes [11], may be used to provide a
../data/rfc/rfc2868.txt: globally unique means to identify a tunnel for accounting and
../data/rfc/rfc2868.txt- auditing purposes.
../data/rfc/rfc2868.txt-
../data/rfc/rfc2868.txt-
../data/rfc/rfc2868.txt-
../data/rfc/rfc2868.txt-
--
../data/rfc/rfc2868.txt-Zorn, et al. Informational [Page 9]
../data/rfc/rfc2868.txt-
../data/rfc/rfc2868.txt-RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
../data/rfc/rfc2868.txt-
../data/rfc/rfc2868.txt-
../data/rfc/rfc2868.txt: particular interface. It SHOULD be included in Accounting-Request
../data/rfc/rfc2868.txt- packets which contain Acct-Status-Type attributes with values of
../data/rfc/rfc2868.txt- either Start or Stop and which pertain to a tunneled session.
../data/rfc/rfc2868.txt-
../data/rfc/rfc2868.txt- A summary of the Tunnel-Private-Group-ID Attribute format is shown
../data/rfc/rfc2868.txt- below. The fields are transmitted from left to right.
--
../data/rfc/rfc2868.txt-
../data/rfc/rfc2868.txt- This attribute MAY be included in the Access-Accept. The tunnel
../data/rfc/rfc2868.txt- initiator receiving this attribute MAY choose to ignore it and
../data/rfc/rfc2868.txt- assign the session to an arbitrary multiplexed or non-multiplexed
../data/rfc/rfc2868.txt- tunnel between the desired endpoints. This attribute SHOULD also
../data/rfc/rfc2868.txt: be included in Accounting-Request packets which contain Acct-
../data/rfc/rfc2868.txt- Status-Type attributes with values of either Start or Stop and
../data/rfc/rfc2868.txt- which pertain to a tunneled session.
../data/rfc/rfc2868.txt-
../data/rfc/rfc2868.txt- If a tunnel initiator supports the Tunnel-Assignment-ID Attribute,
../data/rfc/rfc2868.txt- then it should assign a session to a tunnel in the following
--
../data/rfc/rfc2868.txt- during the authentication phase of tunnel establishment. The
../data/rfc/rfc2868.txt- Tunnel-Client-Auth-ID Attribute MAY be included (as a hint to the
../data/rfc/rfc2868.txt- RADIUS server) in the Access-Request packet, and MUST be included
../data/rfc/rfc2868.txt- in the Access-Accept packet if an authentication name other than
../data/rfc/rfc2868.txt- the default is desired. This Attribute SHOULD be included in
../data/rfc/rfc2868.txt: Accounting-Request packets which contain Acct-Status-Type
../data/rfc/rfc2868.txt- attributes with values of either Start or Stop and which pertain
../data/rfc/rfc2868.txt- to a tunneled session.
../data/rfc/rfc2868.txt-
../data/rfc/rfc2868.txt-
../data/rfc/rfc2868.txt-
--
../data/rfc/rfc2868.txt- during the authentication phase of tunnel establishment. The
../data/rfc/rfc2868.txt- Tunnel-Client-Auth-ID Attribute MAY be included (as a hint to the
../data/rfc/rfc2868.txt- RADIUS server) in the Access-Request packet, and MUST be included
../data/rfc/rfc2868.txt- in the Access-Accept packet if an authentication name other than
../data/rfc/rfc2868.txt- the default is desired. This Attribute SHOULD be included in
../data/rfc/rfc2868.txt: Accounting-Request packets which contain Acct-Status-Type
../data/rfc/rfc2868.txt- attributes with values of either Start or Stop and which pertain
../data/rfc/rfc2868.txt- to a tunneled session.
../data/rfc/rfc2868.txt-
../data/rfc/rfc2868.txt- A summary of the Tunnel-Server-Auth-ID Attribute format is shown
../data/rfc/rfc2868.txt- below. The fields are transmitted from left to right.
--
../data/rfc/rfc2868.txt- [9] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing
../data/rfc/rfc2868.txt- Encapsulation (GRE)", RFC 1701, October 1994.
../data/rfc/rfc2868.txt-
../data/rfc/rfc2868.txt- [10] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
../data/rfc/rfc2868.txt-
../data/rfc/rfc2868.txt: [11] Zorn, G. and D. Mitton, "RADIUS Accounting Modifications for
../data/rfc/rfc2868.txt- Tunnel Protocol Support", RFC 2867, June 2000.
../data/rfc/rfc2868.txt-
../data/rfc/rfc2868.txt- [12] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
../data/rfc/rfc2868.txt- Authentication Dial in User Service (RADIUS)", RFC 2865, June
../data/rfc/rfc2868.txt- 2000.
--
../data/rfc/rfc8309.txt- A service may be limited to simple connectivity (such as IP-based
../data/rfc/rfc8309.txt- Internet access), may be a tunnel (such as a virtual circuit), or
../data/rfc/rfc8309.txt- may involve more complex connectivity (such as in a multisite
../data/rfc/rfc8309.txt- virtual private network). Services may be further enhanced by
../data/rfc/rfc8309.txt- additional functions providing security, load balancing,
../data/rfc/rfc8309.txt: accounting, and so forth. Additionally, services usually include
../data/rfc/rfc8309.txt- guarantees of quality, throughput, and fault reporting.
../data/rfc/rfc8309.txt-
../data/rfc/rfc8309.txt- This document makes a distinction between a service as delivered
../data/rfc/rfc8309.txt- to a customer (that is, the service as discussed on the interface
../data/rfc/rfc8309.txt- between a customer and the network operator) and the service as
--
../data/rfc/rfc8559.txt- 2. Problem Statement ...............................................5
../data/rfc/rfc8559.txt- 2.1. Typical RADIUS Proxying ....................................5
../data/rfc/rfc8559.txt- 2.2. CoA Processing .............................................6
../data/rfc/rfc8559.txt- 2.3. Failure of CoA Proxying ....................................6
../data/rfc/rfc8559.txt- 3. How to Perform CoA Proxying .....................................7
../data/rfc/rfc8559.txt: 3.1. Changes to Access-Request and Accounting-Request Packets ...8
../data/rfc/rfc8559.txt- 3.2. Proxying of CoA-Request and Disconnect-Request Packets .....9
../data/rfc/rfc8559.txt- 3.3. Reception of CoA-Request and Disconnect-Request Packets ...10
../data/rfc/rfc8559.txt- 3.4. Operator-NAS-Identifier ...................................11
../data/rfc/rfc8559.txt- 4. Requirements ...................................................14
../data/rfc/rfc8559.txt- 4.1. Requirements on Home Servers ..............................14
--
../data/rfc/rfc8559.txt- methods of proxying CoA packets are possible but are not discussed
../data/rfc/rfc8559.txt- here.
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt- In order to determine the "next hop" for a packet, the proxying
../data/rfc/rfc8559.txt- server looks up the "realm" portion of the NAI in a logical
../data/rfc/rfc8559.txt: Authentication, Authorization, and Accounting (AAA) routing table, as
../data/rfc/rfc8559.txt- described in Section 3 of [RFC7542]. The entry in that table
../data/rfc/rfc8559.txt- contains information about the next hop to which the packet is sent.
../data/rfc/rfc8559.txt- This information can be IP address, shared secret, certificate, etc.
../data/rfc/rfc8559.txt- The next hop may also be another proxy, or it may be the home server
../data/rfc/rfc8559.txt- for that realm.
--
../data/rfc/rfc8559.txt- sessions. That is, once a response has been sent by the proxy, it
../data/rfc/rfc8559.txt- can discard all information about the request packet, other than what
../data/rfc/rfc8559.txt- is needed for detecting retransmissions as per Section 2.2.2 of
../data/rfc/rfc8559.txt- [RFC5080].
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt: The same method is used to proxy Accounting-Request packets.
../data/rfc/rfc8559.txt: Proxying both Access-Request and Accounting-Request packets allows
../data/rfc/rfc8559.txt- proxies to connect visited networks to home networks for all AAA
../data/rfc/rfc8559.txt- purposes.
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt-2.2. CoA Processing
../data/rfc/rfc8559.txt-
--
../data/rfc/rfc8559.txt- the Operator-Name attribute MUST NOT occur more than once in a
../data/rfc/rfc8559.txt- packet. If a packet contains more than one Operator-Name,
../data/rfc/rfc8559.txt- implementations MUST treat the second and subsequent attributes as
../data/rfc/rfc8559.txt- "invalid attributes", as discussed in Section 2.8 of [RFC6929].
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt:3.1. Changes to Access-Request and Accounting-Request Packets
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt: When a visited network proxies an Access-Request or Accounting-
../data/rfc/rfc8559.txt- Request packet outside of its network, a visited network that wishes
../data/rfc/rfc8559.txt- to support realm-based CoA proxying SHOULD include an Operator-Name
../data/rfc/rfc8559.txt- attribute in the packet, as discussed in Section 4.1 of [RFC5580].
../data/rfc/rfc8559.txt- The contents of the Operator-Name attribute should be "1", followed
../data/rfc/rfc8559.txt- by the realm name of the visited network. Where the visited network
../data/rfc/rfc8559.txt- has more than one realm name, a "canonical" name SHOULD be chosen and
../data/rfc/rfc8559.txt- used for all packets.
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt- Visited networks MUST use a consistent value for Operator-Name for
../data/rfc/rfc8559.txt- any one user session. That is, sending "1example.com" in an
../data/rfc/rfc8559.txt: Access-Request packet and "1example.org" in an Accounting-Request
../data/rfc/rfc8559.txt- packet for that same session is forbidden. Such behavior would make
../data/rfc/rfc8559.txt- it look like a single user session was active simultaneously in two
../data/rfc/rfc8559.txt- different visited networks, which is impossible.
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt- Proxies that record user session information SHOULD also record
--
../data/rfc/rfc8559.txt- Identification Mismatch").
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt- All other received packets are processed as per local site rules and
../data/rfc/rfc8559.txt- will result in an appropriate response packet being sent. This
../data/rfc/rfc8559.txt- process mirrors the method used to process Access-Request and
../data/rfc/rfc8559.txt: Accounting-Request packets (described above).
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt-
--
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt-3.4. Operator-NAS-Identifier
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt- The Operator-NAS-Identifier attribute is an opaque token that
../data/rfc/rfc8559.txt- identifies an individual NAS in a visited network. It MAY appear in
../data/rfc/rfc8559.txt: the following packets: Access-Request, Accounting-Request,
../data/rfc/rfc8559.txt- CoA-Request, or Disconnect-Request. Operator-NAS-Identifier MUST NOT
../data/rfc/rfc8559.txt- appear in any other packets.
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt- Operator-NAS-Identifier MAY occur in a packet if the packet also
../data/rfc/rfc8559.txt- contains an Operator-Name attribute. Operator-NAS-Identifier
--
../data/rfc/rfc8559.txt- packet. If a packet contains more than one Operator-NAS-Identifier,
../data/rfc/rfc8559.txt- implementations MUST treat the second and subsequent attributes as
../data/rfc/rfc8559.txt- "invalid attributes", as discussed in Section 2.8 of [RFC6929].
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt- An Operator-NAS-Identifier attribute SHOULD be added to an
../data/rfc/rfc8559.txt: Access-Request or Accounting-Request packet by a visited network,
../data/rfc/rfc8559.txt- before proxying a packet to an external RADIUS server. When the
../data/rfc/rfc8559.txt- Operator-NAS-Identifier attribute is added to a packet, the following
../data/rfc/rfc8559.txt- attributes SHOULD be deleted from the packet: NAS-IP-Address,
../data/rfc/rfc8559.txt- NAS-IPv6-Address, and NAS-Identifier. If these attributes are
../data/rfc/rfc8559.txt- deleted, the proxy MUST then add a new NAS-Identifier attribute,
--
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt- Note that there is no requirement that the value of Operator-NAS-
../data/rfc/rfc8559.txt- Identifier be checked for integrity. Modification of the value
../data/rfc/rfc8559.txt- can only result in the erroneous transaction being rejected.
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt: We note that the Access-Request and Accounting-Request packets
../data/rfc/rfc8559.txt- often contain the Media Access Control (MAC) address of the NAS.
../data/rfc/rfc8559.txt- There is therefore no requirement that Operator-NAS-Identifier
../data/rfc/rfc8559.txt- obfuscate or hide in any way the total number of NASes in a
../data/rfc/rfc8559.txt- visited network. That information is already public knowledge.
../data/rfc/rfc8559.txt-
--
../data/rfc/rfc8559.txt- NAK packet that contains an Error-Cause Attribute having value 503
../data/rfc/rfc8559.txt- ("Session Context Not Found"). These checks cannot be mandated due
../data/rfc/rfc8559.txt- to the fact that [RFC5176] offers no advice on which attributes are
../data/rfc/rfc8559.txt- used to identify a user's session.
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt: Because a RADIUS proxy will see Access-Request and Accounting-Request
../data/rfc/rfc8559.txt- packets, we recognize that it will have sufficient information to
../data/rfc/rfc8559.txt- forge CoA packets. The RADIUS proxy will thus have the ability to
../data/rfc/rfc8559.txt- subsequently disconnect any user who was authenticated through
../data/rfc/rfc8559.txt- itself.
../data/rfc/rfc8559.txt-
--
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt- The biggest problem is that there are no provisions in RADIUS for
../data/rfc/rfc8559.txt- "end-to-end" security. That is, the visited network and home network
../data/rfc/rfc8559.txt- cannot communicate privately in the presence of proxies. This
../data/rfc/rfc8559.txt- limitation originates from the design of RADIUS for Access-Request
../data/rfc/rfc8559.txt: and Accounting-Request packets. That limitation is then carried over
../data/rfc/rfc8559.txt- to CoA-Request and Disconnect-Request packets.
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt-
--
../data/rfc/rfc8559.txt- the NAS.
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt- When Operator-Name and/or Operator-NAS-Identifier are received by a
../data/rfc/rfc8559.txt- proxy, the proxy MUST pass those attributes through unchanged. This
../data/rfc/rfc8559.txt- requirement applies to all proxies, including proxies that forward
../data/rfc/rfc8559.txt: any or all of Access-Request, Accounting-Request, CoA-Request, and
../data/rfc/rfc8559.txt- Disconnect-Request packets.
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt- All attributes added by a RADIUS proxy when sending packets from the
../data/rfc/rfc8559.txt- visited network to the home network MUST be removed by the
../data/rfc/rfc8559.txt- corresponding CoA proxy from packets traversing the reverse path.
--
../data/rfc/rfc8559.txt- trust instead of on technical means.
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt- CoA packet proxying has all of the same issues as those noted above.
../data/rfc/rfc8559.txt- We note that the proxies that see and can modify CoA packets are
../data/rfc/rfc8559.txt- generally the same proxies that can see or modify Access-Request and
../data/rfc/rfc8559.txt: Accounting-Request packets. As such, there are few additional
../data/rfc/rfc8559.txt- security implications in allowing CoA proxying.
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt- The main security implication that remains is that home networks now
../data/rfc/rfc8559.txt- have the ability to disconnect or change the authorization of users
../data/rfc/rfc8559.txt- in a visited network. As this capability is only enabled when mutual
--
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt- Trusted parties can modify a user's session on the NAS only when they
../data/rfc/rfc8559.txt- have sufficient information to identify that session. In practice,
../data/rfc/rfc8559.txt- this limitation means that those parties already have access to the
../data/rfc/rfc8559.txt- user's session information. In other words, those parties are the
../data/rfc/rfc8559.txt: proxies who are already forwarding Access-Request and Accounting-
../data/rfc/rfc8559.txt- Request packets.
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt-
--
../data/rfc/rfc8559.txt- DOI 10.17487/RFC8174, May 2017,
../data/rfc/rfc8559.txt- <https://www.rfc-editor.org/info/rfc8174>.
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt-8.2. Informative References
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866,
../data/rfc/rfc8559.txt- DOI 10.17487/RFC2866, June 2000,
../data/rfc/rfc8559.txt- <https://www.rfc-editor.org/info/rfc2866>.
../data/rfc/rfc8559.txt-
../data/rfc/rfc8559.txt-Authors' Addresses
../data/rfc/rfc8559.txt-
--
../data/rfc/rfc599.txt- regardless of the terminal option. See Reference 9 for
../data/rfc/rfc599.txt- discussion of the virtues of compression.
../data/rfc/rfc599.txt-
../data/rfc/rfc599.txt- 2. Automatic Coldstart Job Resubmission
../data/rfc/rfc599.txt-
../data/rfc/rfc599.txt: If "R" (Restart) is specified in the accounting field on the
../data/rfc/rfc599.txt- JOB card and if this option is chosen, RJS will automatically
../data/rfc/rfc599.txt- resubmit the job from the beginning if the CCN operating system
../data/rfc/rfc599.txt- should be "coldstarted" before all output from the job is
../data/rfc/rfc599.txt- returned. Otherwise, the job will be lost and must be
../data/rfc/rfc599.txt- resubmitted from the remote terminal in case of a coldstart.
--
../data/rfc/rfc3127.txt- B. Wolff
../data/rfc/rfc3127.txt- Databus Inc.
../data/rfc/rfc3127.txt- June 2001
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: Authentication, Authorization, and Accounting:
../data/rfc/rfc3127.txt- Protocol Evaluation
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt-Status of this Memo
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- This memo provides information for the Internet community. It does
--
../data/rfc/rfc3127.txt- Copyright (C) The Internet Society (2001). All Rights Reserved.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt-Abstract
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- This memo represents the process and findings of the Authentication,
../data/rfc/rfc3127.txt: Authorization, and Accounting Working Group (AAA WG) panel evaluating
../data/rfc/rfc3127.txt- protocols proposed against the AAA Network Access Requirements, RFC
../data/rfc/rfc3127.txt- 2989. Due to time constraints of this report, this document is not
../data/rfc/rfc3127.txt- as fully polished as it might have been desired. But it remains
../data/rfc/rfc3127.txt- mostly in this state to document the results as presented.
../data/rfc/rfc3127.txt-
--
../data/rfc/rfc3127.txt- 2. Protocol Proposals . . . . . . . . . . . . . . . . . . . . . . .8
../data/rfc/rfc3127.txt- 3. Item Level Compliance Evaluation . . . . . . . . . . . . . . . 8
../data/rfc/rfc3127.txt- 3.1 General Requirements . . . . . . . . . . . . . . . . . . . . . 9
../data/rfc/rfc3127.txt- 3.2 Authentication Requirements. . . . . . . . . . . . . . . . . .11
../data/rfc/rfc3127.txt- 3.3 Authorization Requirements . . . . . . . . . . . . . . . . . .12
../data/rfc/rfc3127.txt: 3.4 Accounting Requirements . . . . . . . . . . . . . . . . . . .12
../data/rfc/rfc3127.txt- 3.5 MOBILE IP Requirements . . . . . . . . . . . . . . . . . . . .13
../data/rfc/rfc3127.txt- 4. Protocol Evaluation Summaries . . . . . . . . . . . . . . . . .14
../data/rfc/rfc3127.txt- 4.1 SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
../data/rfc/rfc3127.txt- 4.2 Radius++ . . . . . . . . . . . . . . . . . . . . . . . . . . .14
../data/rfc/rfc3127.txt- 4.3 Diameter . . . . . . . . . . . . . . . . . . . . . . . . . . .14
--
../data/rfc/rfc3127.txt- A. Appendix A - Summary Evaluations . . . . . . . . . . . . . . .17
../data/rfc/rfc3127.txt- B. Appendix B - Review of the Requirements . . . . . . . . . . . .18
../data/rfc/rfc3127.txt- B.1 General Requirements. . . . . . . . . . . . . . . . . . . . . .18
../data/rfc/rfc3127.txt- B.2 Authentication Requirements . . . . . . . . . . . . . . . . . .19
../data/rfc/rfc3127.txt- B.3 Authorization Requirements. . . . . . . . . . . . . . . . . . .19
../data/rfc/rfc3127.txt: B.4 Accounting Requirements . . . . . . . . . . . . . . . . . . . .20
../data/rfc/rfc3127.txt- C. Appendix C - Position Briefs . . . . . . . . . . . . . . . . .21
../data/rfc/rfc3127.txt- C.1 SNMP PRO Evaluation . . . . . . . . . . . . . . . . . . . . .21
../data/rfc/rfc3127.txt- C.2 SNMP CON Evaluation . . . . . . . . . . . . . . . . . . . . .28
../data/rfc/rfc3127.txt- C.3 RADIUS+ PRO Evaluation . . . . . . . . . . . . . . . . . . . .33
../data/rfc/rfc3127.txt- C.4 RADIUS+ CON Evaluation . . . . . . . . . . . . . . . . . . . .37
--
../data/rfc/rfc3127.txt- did a requirement by requirement discussion, then a discussion of
../data/rfc/rfc3127.txt- each of the protocols.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- The final phase was for each member to provide his final summary
../data/rfc/rfc3127.txt- evaluation for each of the protocols. Each proposal was scored as
../data/rfc/rfc3127.txt: either Not Acceptable, Acceptable Only For Accounting, Acceptable
../data/rfc/rfc3127.txt- with Engineering and Fully Acceptable. Where a proposal was
../data/rfc/rfc3127.txt- acceptable with engineering, the member indicated whether it would be
../data/rfc/rfc3127.txt- a small, medium or large amount.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- It should be noted that score indicated the opinion of the team
--
../data/rfc/rfc3127.txt- All of the protocols were weak to non-existent on specifying how this
../data/rfc/rfc3127.txt- would be done in a web of proxies situation.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 3.3.8 Unsolicited Disconnect - SNMP:T, RADIUS:P, Diameter:T, COPS:T
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt:3.4 Accounting Requirements
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 3.4.1 Real Time Accounting - SNMP:T, RADIUS:T, Diameter:T, COPS:T
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt-
--
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 3.4.2 Mandatory Compact Encoding - SNMP:T, RADIUS:T, Diameter:T,
../data/rfc/rfc3127.txt- COPS:T
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 3.4.3 Accounting Record Extensibility - SNMP:T, RADIUS:T,
../data/rfc/rfc3127.txt- Diameter:T, COPS:T
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 3.4.4 Batch Accounting - SNMP:T, RADIUS:F, Diameter:P, COPS:P
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- Some members of the group are not sure how this fits into the rest of
../data/rfc/rfc3127.txt- the AAA protocol, which is primarily real-time and event driven.
../data/rfc/rfc3127.txt- Would this be better met with FTP?
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 3.4.5 Guaranteed Delivery - SNMP:T, RADIUS:T, Diameter:T, COPS:T
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 3.4.6 Accounting Timestamps - SNMP:T, RADIUS:T, Diameter:T,
../data/rfc/rfc3127.txt- COPS:T
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 3.4.7 Dynamic Accounting - SNMP:T, RADIUS:T, Diameter:T, COPS:T
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt-3.5 MOBILE IP Requirements
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 3.5.1 Encoding of MOBILE IP Registration Messages - SNMP:T,
../data/rfc/rfc3127.txt- RADIUS:T/P, Diameter:T, COPS:T
--
../data/rfc/rfc3127.txt-4. Protocol Evaluation Summaries
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt-4.1. SNMP
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- SNMP is generally not acceptable as a general AAA protocol. There
../data/rfc/rfc3127.txt: may be some utility in its use for accounting, but the amount of
../data/rfc/rfc3127.txt- engineering to turn it into a viable A&A protocol argues against
../data/rfc/rfc3127.txt- further consideration.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt-4.2. Radius++
../data/rfc/rfc3127.txt-
--
../data/rfc/rfc3127.txt- State Reconciliation - Clarification [f] should be brought in line
../data/rfc/rfc3127.txt- with NASREQ requirements. The clarification imposes overbroad
../data/rfc/rfc3127.txt- requirements not required by NASREQ and NASREQ is the only service
../data/rfc/rfc3127.txt- with requirements in this area.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt:B.4 Accounting Requirements
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: Real-Time accounting - [Table] Replace MOBILE IP footnote [39] with a
../data/rfc/rfc3127.txt- footnote pointing to section 3.1 of [3] as being more appropriate.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- Mandatory Compact Encoding - [Table] Delete MOBILE IP "M" and
../data/rfc/rfc3127.txt- footnote "33" as the reference does not support the requirement.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: Accounting Record Extensibility - [Table] Delete NASREQ "M" and
../data/rfc/rfc3127.txt- footnote "15" as the reference does not support the requirement.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: Accounting Time Stamps - [Table] Delete MOBILE IP "S" and footnote
../data/rfc/rfc3127.txt- "30" as they don't support the requirement. Replace MOBILE IP
../data/rfc/rfc3127.txt- footnote "40" with a footnote pointing to section 3.1 of [3] as being
../data/rfc/rfc3127.txt- more appropriate.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: Dynamic Accounting - [Table] Replace the NASREQ footnote "18" with a
../data/rfc/rfc3127.txt- footnote pointing to section 8.4.1.5 of [3]. Delete the MOBILE IP
../data/rfc/rfc3127.txt- "S" and footnote "30" as the reference does not support the
../data/rfc/rfc3127.txt- requirement.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- Footnote section.
--
../data/rfc/rfc3127.txt- 1.3.8 Unsolicited Disconnect - Grade T
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- The document indicates that SNMP can easily provide objects to
../data/rfc/rfc3127.txt- control this operation.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4 Accounting Requirements
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.1 Real Time Accounting - Grade T
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- SNMP can provide this mode of operation. The document outlines
../data/rfc/rfc3127.txt- methods both fully within SNMP and using SNMP to interface with other
../data/rfc/rfc3127.txt- transfer methods. Many providers already use SNMP for real time
../data/rfc/rfc3127.txt-
--
../data/rfc/rfc3127.txt- protocols to handle data transmissions where the BER encoding of SNMP
../data/rfc/rfc3127.txt- objects would be considered excessive. SNMP BER encoded protocol
../data/rfc/rfc3127.txt- elements are generally in a fairly compact encoding form compared
../data/rfc/rfc3127.txt- with text based forms (as used in some existing radius log file
../data/rfc/rfc3127.txt- implementations). This interacts with the general requirement for
../data/rfc/rfc3127.txt: carrying service specific attributes and the accounting requirement
../data/rfc/rfc3127.txt- for extensibility. With careful MIB design and future work on SNMP
../data/rfc/rfc3127.txt- payload compression the SNMP coding overhead can be comparable with
../data/rfc/rfc3127.txt- other less extensible protocols.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.3 Accounting Record Extensibility - Grade T
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- SNMP has a strong tradition of allowing vendor specific data objects
../data/rfc/rfc3127.txt- to be transferred.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.4 Batch Accounting - Grade T
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- There are many methods which a SNMP based system could use for batch
../data/rfc/rfc3127.txt: accounting. The document discusses SNMP parameters to control the
../data/rfc/rfc3127.txt- batching process and indicates that certain existing MIBs contain
../data/rfc/rfc3127.txt- examples of implementation strategies. SNMP log tables can provide
../data/rfc/rfc3127.txt: accounting information which can be obtained in many methods not
../data/rfc/rfc3127.txt- directly related to real time capabilities. The underlying system
../data/rfc/rfc3127.txt- buffering requirements are similar regardless of the protocol used to
../data/rfc/rfc3127.txt- transport the information.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.4.5 Guaranteed Delivery - Grade T
--
../data/rfc/rfc3127.txt- in a pull model (versus the often assumed push model) the data
../data/rfc/rfc3127.txt- gatherer can absolutely know that all data has been transfered. In
../data/rfc/rfc3127.txt- the common push model the data receiver does not know if the
../data/rfc/rfc3127.txt- originator of the data is having problems delivering the data.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.6 Accounting Timestamps - Grade T
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- Timestamps are used for many SNMP based operations. The document
../data/rfc/rfc3127.txt- points at the DateAndTime textual convention which is available for
../data/rfc/rfc3127.txt- use. As with all environments the timestamps accuracy needs
../data/rfc/rfc3127.txt- evaluation before the information should be relied upon.
--
../data/rfc/rfc3127.txt-Mitton, et al. Informational [Page 26]
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt-RFC 3127 AAA Protocol Evaluation Process June 2001
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.7 Dynamic Accounting - Grade T
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- As long as there is some way to relate multiple records together
../data/rfc/rfc3127.txt- there are no problems resolving multiple records for the same
../data/rfc/rfc3127.txt- session. This interacts with the scalability requirement and care
../data/rfc/rfc3127.txt- must be taken when implementing a system with both of these
--
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.3.8 Unsolicited Disconnect - Assuming that the NAS is an SNMP agent
../data/rfc/rfc3127.txt- for an AAA server acting as an SNMP manager the evaluator concurs.
../data/rfc/rfc3127.txt- Eval - No Change (T).
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4 Accounting Requirements
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.1 Real Time Accounting - SNMP Informs could accomplish the
../data/rfc/rfc3127.txt- requirements. Eval - No Change (T)
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.4.2 Mandatory Compact Encoding - This is a good and reasonable
../data/rfc/rfc3127.txt- response. SNMP can vary the style and type of reported objects to
../data/rfc/rfc3127.txt- meet specific needs. Eval - No Change (T).
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.3 Accounting Record Extensibility - MIBs are extensible. Eval -
../data/rfc/rfc3127.txt- No Change (T)
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.4 Batch Accounting - MIBs provide data collection at various
../data/rfc/rfc3127.txt- times. Eval - No Change (T)
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.4.5 Guaranteed Delivery - There's some weasel wording here with
../data/rfc/rfc3127.txt- respect to what guaranteed means, but the description of mechanisms
../data/rfc/rfc3127.txt- does appear to meet the requirements. Eval - No Change (T)
--
../data/rfc/rfc3127.txt-Mitton, et al. Informational [Page 31]
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt-RFC 3127 AAA Protocol Evaluation Process June 2001
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.6 Accounting Timestamps - Accounting records can use the
../data/rfc/rfc3127.txt- DateAndTime Textual Convention to mark their times. Eval - No Change
../data/rfc/rfc3127.txt- (T)
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.7 Dynamic Accounting - The author may have partially missed the
../data/rfc/rfc3127.txt- point on this requirement. While the number of records per session
../data/rfc/rfc3127.txt- is not of great interest, the delivery may be. The author should go
../data/rfc/rfc3127.txt- a little more into depth on this requirement. Eval - No Change (T)
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.5 MOBILE IP Requirements
--
../data/rfc/rfc3127.txt- The evaluator also notes that the scaling issues of SNMP in SNMP
../data/rfc/rfc3127.txt- agent/manager mode are in no way indicative of SNMP in AAA
../data/rfc/rfc3127.txt- client/server mode. This has a possibility to substantially impair
../data/rfc/rfc3127.txt- SNMPs use in an AAA role.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: However, SNMP may have a reasonable role in the Accounting space.
../data/rfc/rfc3127.txt- SNMP appears to map well with existing technology, and with the
../data/rfc/rfc3127.txt- requirements.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 3. General Requirements
../data/rfc/rfc3127.txt-
--
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 4. Summary Recommendation
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- Recommended in Part. SNMP is NOT RECOMMENDED for use as either an
../data/rfc/rfc3127.txt- authentication or authorization protocol, but IS RECOMMENDED for use
../data/rfc/rfc3127.txt: as an accounting protocol.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt-C.3 RADIUS+ PRO Evaluation
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- Evaluation of RADIUS AAA Requirements PRO Evaluation
../data/rfc/rfc3127.txt-
--
../data/rfc/rfc3127.txt- 1.3.7 [g] State Reconciliation - Eval - F (no change)
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.3.8 [h] Unsolicited Disconnect - RADIUS++ extensions to support.
../data/rfc/rfc3127.txt- Eval - T. (no change)
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4 Accounting Requirements
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.1 [a] Real Time Accounting - Eval - T (no change)
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.4.2 [b] Mandatory Compact Encoding - Eval - T (no change)
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.3 [c] Accounting Record Extensibility - Eval - T (no change)
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.4 [d] Batch Accounting - RADIUS++ offers no new features to
../data/rfc/rfc3127.txt: support batch accounting. Eval - F No change)
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.4.5 [e] Guaranteed Delivery - Retransmission algorithm employed.
../data/rfc/rfc3127.txt- Eval - T (no change)
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.6 [f] Accounting Timestamps - RADIUS++ extensions support
../data/rfc/rfc3127.txt- timestamps. Eval - T (no change)
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.7 [g] Dynamic Accounting - RADIUS++ extensions to support. Eval
../data/rfc/rfc3127.txt- - T (no change)
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.5 MOBILE IP Requirements
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.5.1 [a] Encoding of MOBILE IP Registration Messages - RADIUS++
--
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- RADIUS++ as it could be developed would provide a level of backward
../data/rfc/rfc3127.txt- compatibility that other protocols cannot achieve. By extending
../data/rfc/rfc3127.txt- RADIUS in the simple ways described in the documents listed above,
../data/rfc/rfc3127.txt- the transition from existing RADIUS-based installations to RADIUS++
../data/rfc/rfc3127.txt: installations would be easier. Although accounting continues to be
../data/rfc/rfc3127.txt- weaker than other approaches, the protocol remains a strong contender
../data/rfc/rfc3127.txt- for continued use in the areas of Authorization and Authentication.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt-C.4 RADIUS+ CON Evaluation
../data/rfc/rfc3127.txt-
--
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.3.8 Unsolicited Disconnect - Much of the discussion from the
../data/rfc/rfc3127.txt- previous section applies to this section. The document [1] claims
../data/rfc/rfc3127.txt- "F", and the evaluator concurs.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4 Accounting Requirements
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.1 Real Time Accounting - RADIUS Accounting is widely deployed and
../data/rfc/rfc3127.txt- functions within the definition of real time contained in [3]. The
../data/rfc/rfc3127.txt- document [1] claims "T", and the evaluator concurs.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.2 Mandatory Compact Encoding - RADIUS Accounting contains TLVs
../data/rfc/rfc3127.txt: for relevant accounting information, each of which is fairly compact.
../data/rfc/rfc3127.txt- Note that the term "bloated" in [3] is somewhat subjective. The
../data/rfc/rfc3127.txt- document [1] claims "T", and the evaluator concurs.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.3 Accounting Record Extensibility - RADIUS Accounting may be
../data/rfc/rfc3127.txt- extended by means of new attributes or by using the Vendor-Specific
../data/rfc/rfc3127.txt- attribute. While it has been argued that the existing attribute
../data/rfc/rfc3127.txt- number space is too small for the required expansion capabilities,
../data/rfc/rfc3127.txt- the protocol [2] addresses this problem in section 3.0, and its
../data/rfc/rfc3127.txt- subsections, of [2]. The document [1] claims "T", and the evaluator
../data/rfc/rfc3127.txt- concurs.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.4 Batch Accounting - RADIUS has no explicit provisions for batch
../data/rfc/rfc3127.txt: accounting, nor does the protocol [2] address how this feature might
../data/rfc/rfc3127.txt- be accomplished. The document [1] claims "F", and the evaluator
../data/rfc/rfc3127.txt- concurs.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.5 Guaranteed Delivery - RADIUS Accounting is widely deployed and
../data/rfc/rfc3127.txt- provides guaranteed delivery within the context of the required
../data/rfc/rfc3127.txt- application-level acknowledgment. The document [1] claims "T", and
../data/rfc/rfc3127.txt- the evaluator concurs.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.6 Accounting Timestamps - The document [1] indicates that this
../data/rfc/rfc3127.txt- feature is specified in [4] as the Event-Timestamp attribute. The
../data/rfc/rfc3127.txt- document claims [1] "T", and the evaluator concurs.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.7 Dynamic Accounting - The document [1] indicates that this
../data/rfc/rfc3127.txt: requirement is partially met using the accounting interim update
../data/rfc/rfc3127.txt- message as specified in [4]. In addition, there was work in the
../data/rfc/rfc3127.txt: RADIUS WG regarding session accounting extensions that has not been
../data/rfc/rfc3127.txt- included in [4], i.e., some expired works in progress. The document
../data/rfc/rfc3127.txt- claims [1] "P", and the evaluator concurs.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt-
--
../data/rfc/rfc3127.txt- Evaluator - Basavaraj Patil
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- Ref [1] is "Diameter Framework Document".
../data/rfc/rfc3127.txt- Ref [2] is "Diameter NASREQ Extensions".
../data/rfc/rfc3127.txt- Ref [3] is the AAA evaluation criteria as modified by us.
../data/rfc/rfc3127.txt: Ref [4] is "Diameter Accounting Extensions".
../data/rfc/rfc3127.txt- Ref [5] is "Diameter Mobile IP Extensions".
../data/rfc/rfc3127.txt- Ref [6] is "Diameter Base Protocol".
../data/rfc/rfc3127.txt- Ref [7] is "Diameter Strong Security Extension".
../data/rfc/rfc3127.txt- Ref [8] is "Comparison of Diameter Against AAA Network Access
../data/rfc/rfc3127.txt- Requirements".
--
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- The base protocol [6] defines a set of session termination messages
../data/rfc/rfc3127.txt- which can be used for unsolicited disconnects. Evaluator concurs
../data/rfc/rfc3127.txt- with the "T" compliance on this requirement.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4 Accounting Requirements
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.1 Real Time Accounting
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- Evaluator concurs with the "T" compliance based on explanations in
../data/rfc/rfc3127.txt- [4].
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.4.2 Mandatory Compact Encoding
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: Use of Accounting Data Interchange Format (ADIF)-Record-AVP for
../data/rfc/rfc3127.txt: compact encoding of accounting data. Evaluator concurs with the "T"
../data/rfc/rfc3127.txt- compliance.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.3 Accounting Record Extensibility
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- ADIF can be extended. Evaluator concurs with the "T" compliance.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.4 Batch Accounting
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: Sec 1.2 of [4] provides support for batch accounting.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.4.5 Guaranteed Delivery
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- Sections 2.1/2 of [4] describe messages that are used to guarantee
../data/rfc/rfc3127.txt: delivery of accounting records. Evaluator concurs with the "T"
../data/rfc/rfc3127.txt- compliance.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.6 Accounting Timestamps
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: Timestamp AVP [6] is present in all accounting messages. Evaluator
../data/rfc/rfc3127.txt- concurs with the "T" compliance.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.7 Dynamic Accounting
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: Interim accounting records equivalent to a call-in-progress can be
../data/rfc/rfc3127.txt- sent periodically. Evaluator concurs with the "T" compliance.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt-
--
../data/rfc/rfc3127.txt- no session-id is defined to ask for info on all sessions, not just
../data/rfc/rfc3127.txt- those "owned" by the requester.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.3.8 Unsolicited Disconnect - T
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4 Accounting Requirements
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.1 Real Time Accounting - T
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.4.2 Mandatory Compact Encoding - T
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.3 Accounting Record Extensibility - T
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.4 Batch Accounting - P (was T). The evaluator suspects that
../data/rfc/rfc3127.txt: simply sending multiple accounting records in a single request is not
../data/rfc/rfc3127.txt: how batch accounting should or will be done.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.4.5 Guaranteed Delivery - T
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.6 Accounting Timestamps - T (The evaluator notes with amusement
../data/rfc/rfc3127.txt- that NTP time cycles in 2036, not 2038 as claimed in the Diameter
../data/rfc/rfc3127.txt- drafts. It's Unix time that will set the sign bit in 2038.)
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.7 Dynamic Accounting - T
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.5 MOBILE IP Requirements
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.5.1 Encoding of MOBILE IP Registration Messages - T
../data/rfc/rfc3127.txt-
--
../data/rfc/rfc3127.txt-Mitton, et al. Informational [Page 57]
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt-RFC 3127 AAA Protocol Evaluation Process June 2001
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4 Accounting Requirements
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.1 Real Time Accounting - The document [1] claims "T", and the
../data/rfc/rfc3127.txt- evaluator concurs.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.4.2 Mandatory Compact Encoding - Note that the term "bloated" in
../data/rfc/rfc3127.txt- [3] is somewhat subjective. The document [1] claims "T", and the
../data/rfc/rfc3127.txt- evaluator concurs.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.3 Accounting Record Extensibility - The document [1] claims "T",
../data/rfc/rfc3127.txt- and the evaluator concurs.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.4 Batch Accounting - The protocol [2] [5] does not address how in
../data/rfc/rfc3127.txt- detail this feature might be accomplished. The document [1] claims
../data/rfc/rfc3127.txt- "T", and the awards "P".
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.4.5 Guaranteed Delivery - Guaranteed delivery is provided by TCP.
../data/rfc/rfc3127.txt- The document [1] claims "T", and the evaluator concurs.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.6 Accounting Timestamps - The document [1] claims "T", and the
../data/rfc/rfc3127.txt- evaluator concurs.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.7 Dynamic Accounting - The document [1] claims "T", and the
../data/rfc/rfc3127.txt- evaluator concurs.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.5 MOBILE IP Requirements
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.5.1 Encoding of MOBILE IP Registration Messages - The document [1]
--
../data/rfc/rfc3127.txt- multi-administration situation, or in any proxy situation. Multi-
../data/rfc/rfc3127.txt- server coordination, if allowed, seems to be lacking a description.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.3.8 Unsolicited Disconnect - T
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4 Accounting Requirements
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.1 Real Time Accounting - T
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.4.2 Mandatory Compact Encoding - T This evaluator does not believe
../data/rfc/rfc3127.txt- that ADIF is a compact format. But does believe that the Information
../data/rfc/rfc3127.txt: Model author can design a PIB with accounting statistics that will
../data/rfc/rfc3127.txt- satisfy this requirement.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.3 Accounting Record Extensibility - P (was T) By defining a
../data/rfc/rfc3127.txt- vendor/device specific PIB for additional elements.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.4 Batch Accounting - P (was T) Offered description does not seem
../data/rfc/rfc3127.txt- to match the requirement.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.4.5 Guaranteed Delivery - P (was T) TCP does NOT "guarantee
../data/rfc/rfc3127.txt- delivery", only application Acks can do that. If these acks can be
../data/rfc/rfc3127.txt- generated similar to the description here, then this requirement is
--
../data/rfc/rfc3127.txt-Mitton, et al. Informational [Page 63]
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt-RFC 3127 AAA Protocol Evaluation Process June 2001
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.6 Accounting Timestamps - T Another item for the "Information
../data/rfc/rfc3127.txt- Model" author.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.7 Dynamic Accounting - T Event and interim accounting can be
../data/rfc/rfc3127.txt- supported.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.5 MOBILE IP Requirements
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.5.1 Encoding of MOBILE IP Registration Messages - P (was T) Yet
--
../data/rfc/rfc3127.txt- but workable.
../data/rfc/rfc3127.txt- * With regard to Authentication, every technique can be supported
../data/rfc/rfc3127.txt- although support for PAP or cleartext passwords is weak.
../data/rfc/rfc3127.txt- * With regard to Authorization, there is nothing in the requirements
../data/rfc/rfc3127.txt- that cannot be supported.
../data/rfc/rfc3127.txt: * Accounting everything supported, although there is no specific
../data/rfc/rfc3127.txt- consideration for compact encoding. SNMP not as bloated as ASCII
../data/rfc/rfc3127.txt- or XML based encoding schemes. Requirement for compact encoding
../data/rfc/rfc3127.txt- weakly indicated in requirements anyway. Server-specific
../data/rfc/rfc3127.txt- attributes needed, but compact encoding preclude w/o tradeoffs.
../data/rfc/rfc3127.txt-
--
../data/rfc/rfc3127.txt- response document. * SNMP is just data moving protocol.
../data/rfc/rfc3127.txt- * Message formats not specified.
../data/rfc/rfc3127.txt- * What is the method for supporting authentication? Storing the
../data/rfc/rfc3127.txt- information is handled, but what do the nodes do with it?
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: * The protocol certainly shined in the area of meeting accounting
../data/rfc/rfc3127.txt- requirements.
../data/rfc/rfc3127.txt: * Although SNMP could certainly play a role in the accounting space,
../data/rfc/rfc3127.txt- it is unusable in the areas of Authorization and Authentication.
../data/rfc/rfc3127.txt- * The response document does not address how the problem will be
../data/rfc/rfc3127.txt- solved.
../data/rfc/rfc3127.txt- * It does not address the scalability issues that may arise in the
../data/rfc/rfc3127.txt- transition from a manager-agent mode of operation to a client-
--
../data/rfc/rfc3127.txt- compliance statement.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- Conclusion from Dave : Not recommended (Details in the con
../data/rfc/rfc3127.txt- statement).
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: Q: Is it possible to use it for accounting?
../data/rfc/rfc3127.txt- A: Authentication and Authorization could be separated, but
../data/rfc/rfc3127.txt: Accounting is the weak link in this protocol and hence is not
../data/rfc/rfc3127.txt- suitable.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- - Mark Steven's summary of the Pro statement
../data/rfc/rfc3127.txt- Agreed with most of the observations made by Dave Nelson. The
../data/rfc/rfc3127.txt- biggest thing going for it is that it has been running in this
--
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.3.3/4/5/6/7/8
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- Call dropped. Somebody else needs to fill in here. (Mike ????)
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: Accounting Requirements:
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.1 Real time accounting
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- No dissent. No discussion
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.4.2 Mandatory compact encoding
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- Comment made regarding ASN.1 and XML in this context
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.3 Accounting Record Extensibility
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- No discussion
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.4 Batch Accounting
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- No specific wording in the document to show how this can be done.
../data/rfc/rfc3127.txt: Basically it is real time accounting without the real time
../data/rfc/rfc3127.txt- constraint.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- It may be a trivial issue.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.5/6 Guaranteed Delivery/Accounting Timestamps
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- No Discussion
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.7 Dynamic Accounting
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- There is ongoing discussion in the AAA WG on this requirement. The
../data/rfc/rfc3127.txt- RADIUS WG is also discussing this (comment). The idea here is to be
../data/rfc/rfc3127.txt- able to send the equivalent of a phonecall in progress type of
../data/rfc/rfc3127.txt- messages.
--
../data/rfc/rfc3127.txt- ACL: filter style syntax seems inadequate
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- state reconciliation: difficult over global multiple
../data/rfc/rfc3127.txt- administrative domains
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: batch accounting: implementation doesn't meet intended need
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- firewall friendly: until firewalls support SCTP will be failure
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- summary very close
../data/rfc/rfc3127.txt-
--
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.3.8 Unsolicited disconnect
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- No Discussion
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: Accounting Requirements:
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.1 Real time accounting
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- No Discussion
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.4.2 Mandatory compact encoding
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- Is ADIF compact?
../data/rfc/rfc3127.txt- Is ADIF UTF-8 compatible?
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.3 Accounting Record Extensibility
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- No Discussion
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.4 Batch Accounting
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- Diameter okay for small batches. Specification doesn't seem
../data/rfc/rfc3127.txt- suitable for large batch transfers (100,000+ records)
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.4.5 Guaranteed Delivery
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- No Discussion
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.6 Accounting Timestamps
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- No Discussion
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.7 Dynamic Accounting
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- No Discussion
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- Mobile IP Requirements:
../data/rfc/rfc3127.txt-
--
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.3.6 Access Rules - lots of work needed.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.3.7 State Reconciliation - multi-server coordination is an issue.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.4 Batch Accounting - for small batches, perhaps.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.4.5 Guaranteed Delivery - application acks are an area of mystery.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.5.2 Firewall-Friendly - COPS like any Swiss-Army-Knife protocol
../data/rfc/rfc3127.txt- (SNMP) requires the firewall to look inside the packets, because
--
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.4.2 No comment.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.4.3 No comment.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt: 1.4.4 There was significant skepticism regarding batch accounting as
../data/rfc/rfc3127.txt- part of the AAA protocol. How large are the "batches"? Should this
../data/rfc/rfc3127.txt- requirement be met using FTP or something similar?
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- 1.4.5 No comment.
../data/rfc/rfc3127.txt-
--
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- A poll was taken on overall acceptability and effort for each of the
../data/rfc/rfc3127.txt- protocols submitted, for requirements conformance.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- Each member indicated their evaluation in the form of (Acceptable,
../data/rfc/rfc3127.txt: Not-Acceptable) with qualifiers for (Accounting, or effort to change)
../data/rfc/rfc3127.txt- This information will be summarized in the final report.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- A general wrap-up discussion was held.
../data/rfc/rfc3127.txt-
../data/rfc/rfc3127.txt- It was considered important that as much of the thought processes and
--
../data/rfc/rfc6709.txt-4.5. Cryptographic Agility
../data/rfc/rfc6709.txt-
../data/rfc/rfc6709.txt- Extensibility with respect to cryptographic algorithms is desirable
../data/rfc/rfc6709.txt- in order to provide resilience against the compromise of any
../data/rfc/rfc6709.txt- particular algorithm. Section 3 of "Guidance for Authentication,
../data/rfc/rfc6709.txt: Authorization, and Accounting (AAA) Key Management" BCP 132 [RFC4962]
../data/rfc/rfc6709.txt- provides some basic advice:
../data/rfc/rfc6709.txt-
../data/rfc/rfc6709.txt- The ability to negotiate the use of a particular cryptographic
../data/rfc/rfc6709.txt- algorithm provides resilience against compromise of a particular
../data/rfc/rfc6709.txt- cryptographic algorithm.... This is usually accomplished by
--
../data/rfc/rfc6709.txt- for Multiprotocol Label Switching (MPLS) and Generalized
../data/rfc/rfc6709.txt- MPLS (GMPLS) Protocols and Procedures", BCP 129, RFC 4929,
../data/rfc/rfc6709.txt- June 2007.
../data/rfc/rfc6709.txt-
../data/rfc/rfc6709.txt- [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
../data/rfc/rfc6709.txt: Authorization, and Accounting (AAA) Key Management", BCP
../data/rfc/rfc6709.txt- 132, RFC 4962, July 2007.
../data/rfc/rfc6709.txt-
../data/rfc/rfc6709.txt- [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication
../data/rfc/rfc6709.txt- Dial In User Service (RADIUS) Implementation Issues and
../data/rfc/rfc6709.txt- Suggested Fixes", RFC 5080, December 2007.
--
../data/rfc/rfc5677.txt- DHCP servers.
../data/rfc/rfc5677.txt-
../data/rfc/rfc5677.txt- Domain Name System (DNS): a protocol described in [RFC1035] that
../data/rfc/rfc5677.txt- translates domain names to IP addresses.
../data/rfc/rfc5677.txt-
../data/rfc/rfc5677.txt: Authentication, Authorization, and Accounting (AAA): a set of network
../data/rfc/rfc5677.txt- management services that respectively determine the validity of a
../data/rfc/rfc5677.txt- user's ID, determine whether a user is allowed to use network
../data/rfc/rfc5677.txt- resources, and track users' use of network resources.
../data/rfc/rfc5677.txt-
../data/rfc/rfc5677.txt- Home AAA (AAAh): an AAA server located on the MN's home network.
--
../data/rfc/rfc6058.txt- LMA by means of signaling. An LMA can establish or change the
../data/rfc/rfc6058.txt- settings of a transient binding according to events, such as a
../data/rfc/rfc6058.txt- timeout, a change of the radio technology due to a handover, or a
../data/rfc/rfc6058.txt- completed set up of a radio bearer or configuration of an MN's IP
../data/rfc/rfc6058.txt- address. Such an event may also be triggered by other protocols,
../data/rfc/rfc6058.txt: e.g., Authentication, Authorization, and Accounting (AAA) messages.
../data/rfc/rfc6058.txt- This document specifies advanced binding cache control by means of a
../data/rfc/rfc6058.txt- Transient Binding option, which can be used with PMIPv6 signaling to
../data/rfc/rfc6058.txt- support transient BCEs. Furthermore, this document specifies
../data/rfc/rfc6058.txt- forwarding characteristics according to the current state of a
../data/rfc/rfc6058.txt- binding to switch the forwarding tunnel at the LMA from the pMAG to
--
../data/rfc/rfc2661.txt- The Remote System initiates a PPP connection across the PSTN Cloud to
../data/rfc/rfc2661.txt- an LAC. The LAC then tunnels the PPP connection across the Internet,
../data/rfc/rfc2661.txt- Frame Relay, or ATM Cloud to an LNS whereby access to a Home LAN is
../data/rfc/rfc2661.txt- obtained. The Remote System is provided addresses from the HOME LAN
../data/rfc/rfc2661.txt-
../data/rfc/rfc2661.txt: via PPP NCP negotiation. Authentication, Authorization and Accounting
../data/rfc/rfc2661.txt- may be provided by the Home LAN's Management Domain as if the user
../data/rfc/rfc2661.txt- were connected to a Network Access Server directly.
../data/rfc/rfc2661.txt-
../data/rfc/rfc2661.txt- A LAC Client (a Host which runs L2TP natively) may also participate
../data/rfc/rfc2661.txt- in tunneling to the Home LAN without use of a separate LAC. In this
../data/rfc/rfc2661.txt- case, the Host containing the LAC Client software already has a
../data/rfc/rfc2661.txt- connection to the public Internet. A "virtual" PPP connection is then
../data/rfc/rfc2661.txt- created and the local L2TP LAC Client software creates a tunnel to
../data/rfc/rfc2661.txt- the LNS. As in the above case, Addressing, Authentication,
../data/rfc/rfc2661.txt: Authorization and Accounting will be provided by the Home LAN's
../data/rfc/rfc2661.txt- Management Domain.
../data/rfc/rfc2661.txt-
../data/rfc/rfc2661.txt-
../data/rfc/rfc2661.txt-
../data/rfc/rfc2661.txt-
--
../data/rfc/rfc5944.txt-
../data/rfc/rfc5944.txt- When the mobile node receives an Agent Advertisement with the 'R' bit
../data/rfc/rfc5944.txt- set, the mobile node SHOULD register through the foreign agent, even
../data/rfc/rfc5944.txt- when the mobile node might be able to acquire its own co-located
../data/rfc/rfc5944.txt- care-of address. This feature is intended to allow sites to enforce
../data/rfc/rfc5944.txt: visiting policies (such as accounting) that require exchanges of
../data/rfc/rfc5944.txt- authorization.
../data/rfc/rfc5944.txt-
../data/rfc/rfc5944.txt- If formerly reserved bits require some kind of monitoring/enforcement
../data/rfc/rfc5944.txt- at the foreign link, foreign agents implementing the new
../data/rfc/rfc5944.txt- specification for the formerly reserved bits can set the 'R' bit.
--
../data/rfc/rfc5944.txt-
../data/rfc/rfc5944.txt- [45] Stevens, R., "TCP/IP Illustrated, Volume 1: The Protocols",
../data/rfc/rfc5944.txt- Addison-Wesley, Reading, Massachusetts, 1994.
../data/rfc/rfc5944.txt-
../data/rfc/rfc5944.txt- [46] Perkins, C. and P. Calhoun, "Authentication, Authorization, and
../data/rfc/rfc5944.txt: Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957,
../data/rfc/rfc5944.txt- March 2005.
../data/rfc/rfc5944.txt-
../data/rfc/rfc5944.txt- [47] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51,
../data/rfc/rfc5944.txt- RFC 1661, July 1994.
../data/rfc/rfc5944.txt-
--
../data/rfc/rfc870.txt- 1-149 1-225 Unassigned [JBP]
../data/rfc/rfc870.txt- 150 226 Xerox NS IP [62,LLG]
../data/rfc/rfc870.txt- 151 227 Unassigned [JBP]
../data/rfc/rfc870.txt- 152 230 PARC Universal Protocol [6,EAT3]
../data/rfc/rfc870.txt- 153 231 TIP Status Reporting [JGH]
../data/rfc/rfc870.txt: 154 232 TIP Accounting [JGH]
../data/rfc/rfc870.txt- 155 233 Internet Protocol (regular) [16,47,JBP]
../data/rfc/rfc870.txt- 156-158 234-236 Internet Protocol (experimental) [16,47,JBP]
../data/rfc/rfc870.txt- 159-195 237-303 Unassigned [JBP]
../data/rfc/rfc870.txt- 196-255 304-377 Experimental Protocols [JBP]
../data/rfc/rfc870.txt- 248-255 370-377 Network Maintenance [JGH]
--
../data/rfc/rfc1678.txt- path.
../data/rfc/rfc1678.txt-
../data/rfc/rfc1678.txt- Corporate networks must meet promised levels of service while
../data/rfc/rfc1678.txt- controlling costs through efficient use of resources. The IETF
../data/rfc/rfc1678.txt- should consider both technical solutions (such as service classes and
../data/rfc/rfc1678.txt: priorities) and administrative ones (such as accounting) to promote
../data/rfc/rfc1678.txt- economy.
../data/rfc/rfc1678.txt-
../data/rfc/rfc1678.txt- Many businesses will not connect to a network until they are
../data/rfc/rfc1678.txt- confident that it will not significantly threaten the
../data/rfc/rfc1678.txt- confidentiality, integrity, or availability of their data.
--
../data/rfc/rfc1678.txt- To discourage waste of bandwidth and other expensive resources,
../data/rfc/rfc1678.txt- corporations want to account for their use. Direct cost recovery
../data/rfc/rfc1678.txt- would let an entity measure and benchmark its efficiency with minimal
../data/rfc/rfc1678.txt- economic distortion. Alternatives, such as placing these costs into
../data/rfc/rfc1678.txt- corporate overhead or charging per connection, make sense when the
../data/rfc/rfc1678.txt: administrative cost of implementing usage-based accounting is high
../data/rfc/rfc1678.txt- enough to introduce more economic distortion than the alternatives
../data/rfc/rfc1678.txt- would. For example, connection-based costs alone may be adequate for
../data/rfc/rfc1678.txt- a resource (such as LAN bandwidth) that is not scarce or expensive,
../data/rfc/rfc1678.txt- but a combination of a connection cost and a usage cost may be more
../data/rfc/rfc1678.txt- appropriate for a more scarce or expensive resource (such as WAN
../data/rfc/rfc1678.txt- bandwidth). Balance must be maintained between the overhead of
../data/rfc/rfc1678.txt: accounting and the granularity of cost allocation.
../data/rfc/rfc1678.txt-
../data/rfc/rfc1678.txt-Security
../data/rfc/rfc1678.txt-
../data/rfc/rfc1678.txt- Many corporations will stick with their private networks until public
../data/rfc/rfc1678.txt- ones can guarantee equivalent confidentiality, integrity, and
--
../data/rfc/rfc1678.txt-
../data/rfc/rfc1678.txt-RFC 1678 IPng Requirements of Large Corporate Networks August 1994
../data/rfc/rfc1678.txt-
../data/rfc/rfc1678.txt-
../data/rfc/rfc1678.txt- discourage inappropriate reservation of resources; e.g., a Telnet
../data/rfc/rfc1678.txt: connection probably doesn't need to reserve 45Mbps. Accounting,
../data/rfc/rfc1678.txt- class-of-service, and well-known-port distinctions are possible ways
../data/rfc/rfc1678.txt- to satisfy that requirement.
../data/rfc/rfc1678.txt-
../data/rfc/rfc1678.txt-Mobile Hosts
../data/rfc/rfc1678.txt-
--
../data/rfc/rfc1168.txt- contains the destination Internet addresses. Figure 4a illustrates
../data/rfc/rfc1168.txt- the path of mail from the Internet to the commercial sytems. Figure
../data/rfc/rfc1168.txt- 4b illustrates the path from the commercial systrems to the Internet.
../data/rfc/rfc1168.txt- Note: MCI Mail is not yet implemented.
../data/rfc/rfc1168.txt-
../data/rfc/rfc1168.txt: The CMR employs a simple accounting mechanism: a shell script counts
../data/rfc/rfc1168.txt- the number of times a string marker occurs in the MMDF logs. At the
../data/rfc/rfc1168.txt- end of the month, another script uses an "awk" program to total the
../data/rfc/rfc1168.txt- number of messages sent and received with each commercial system. The
../data/rfc/rfc1168.txt- Commercial Mail Relay is being developed by Craig E. Ward. Ann
../data/rfc/rfc1168.txt- Westine served as the Postmaster for both Intermail and the CMR until
--
../data/rfc/rfc1168.txt- The commercial systems are geared for paying customers to send and
../data/rfc/rfc1168.txt- receive mail to other paying customers. They are not equipped to
../data/rfc/rfc1168.txt- handle reverse billing, or "collect calls." ISI is currently charged
../data/rfc/rfc1168.txt- for connect time needed to transmit and receive mail to and from
../data/rfc/rfc1168.txt- other Internet sites. A possible solution to this problem would be
../data/rfc/rfc1168.txt: to extend the CMR. to include accounting and billing procedures that
../data/rfc/rfc1168.txt- would pass the costs of CMR to its users.
../data/rfc/rfc1168.txt-
../data/rfc/rfc1168.txt- What had been GTE Telemail became Sprint SprintMail, Telenet became
../data/rfc/rfc1168.txt- Sprintnet, and the host TELEMAIL/USA became SM66/USA.
../data/rfc/rfc1168.txt-
--
../data/rfc/rfc3432.txt- precedence).
../data/rfc/rfc3432.txt-
../data/rfc/rfc3432.txt-4.6 Errors and uncertainties
../data/rfc/rfc3432.txt-
../data/rfc/rfc3432.txt- The description of any specific measurement method should include an
../data/rfc/rfc3432.txt: accounting and analysis of various sources of error or uncertainty.
../data/rfc/rfc3432.txt- The Framework RFC [3] provides general guidance on this point, but we
../data/rfc/rfc3432.txt- note here the following specifics related to periodic streams and
../data/rfc/rfc3432.txt- delay metrics:
../data/rfc/rfc3432.txt-
../data/rfc/rfc3432.txt- + Error due to variation of incT. The reasons for this can be
--
../data/rfc/rfc3432.txt- relevant to this memo. The user's focus is on transport quality
../data/rfc/rfc3432.txt- evaluation from the application point of view. However, to properly
../data/rfc/rfc3432.txt- separate the quality contribution of the operating system and codec
../data/rfc/rfc3432.txt- on packet voice, for example, it is beneficial to be able to measure
../data/rfc/rfc3432.txt- quality at the IP level [6]. Link layer monitoring provides a way of
../data/rfc/rfc3432.txt: accounting for link layer characteristics such as bit error rates.
../data/rfc/rfc3432.txt-
../data/rfc/rfc3432.txt- ---------------
../data/rfc/rfc3432.txt- | application |
../data/rfc/rfc3432.txt- ---------------
../data/rfc/rfc3432.txt- | transport | <--
--
../data/rfc/rfc3432.txt- latter property means that measurement streams are transmitted in
../data/rfc/rfc3432.txt- both directions. Thus, the measurement provides information on
../data/rfc/rfc3432.txt- quality of service as experienced by two-way applications.
../data/rfc/rfc3432.txt-
../data/rfc/rfc3432.txt- The downsides of round-trip measurement are the need for more
../data/rfc/rfc3432.txt: bandwidth than a one-way test and more complex accounting of packet
../data/rfc/rfc3432.txt- loss. Moreover, the stream that is returning towards the original
../data/rfc/rfc3432.txt- sender may be more bursty than the one on the first "leg" of the
../data/rfc/rfc3432.txt-
../data/rfc/rfc3432.txt-
../data/rfc/rfc3432.txt-
--
../data/rfc/rfc5712.txt- and both bandwidth reservations cannot be satisfied on the R1-R4
../data/rfc/rfc5712.txt- link.
../data/rfc/rfc5712.txt-
../data/rfc/rfc5712.txt- Instead of sending a PathTear message for LSP2 upon preemption as
../data/rfc/rfc5712.txt- with hard preemption (which would result in an immediate traffic
../data/rfc/rfc5712.txt: disruption for LSP2), R1's local bandwidth accounting for LSP2 is
../data/rfc/rfc5712.txt- zeroed, and a PathErr message with error code "Reroute" and a value
../data/rfc/rfc5712.txt- "Reroute Request Soft Preemption" for LSP2 is issued.
../data/rfc/rfc5712.txt-
../data/rfc/rfc5712.txt- Upon reception of the PathErr message for LSP2, R2 may update the
../data/rfc/rfc5712.txt- working copy of the TE-DB before calculating a new path for the new
--
../data/rfc/rfc5712.txt-
../data/rfc/rfc5712.txt-RFC 5712 MPLS-TE Soft Preemption January 2010
../data/rfc/rfc5712.txt-
../data/rfc/rfc5712.txt-
../data/rfc/rfc5712.txt- By contrast, the mode of operation with soft preemption is as
../data/rfc/rfc5712.txt: follows: the preempting node's local bandwidth accounting for the
../data/rfc/rfc5712.txt- preempted TE LSP is zeroed and a PathErr with error code "Reroute",
../data/rfc/rfc5712.txt- and a error value "Reroute Request Soft Preemption" for that TE LSP
../data/rfc/rfc5712.txt- is issued upstream toward the head-end LSR.
../data/rfc/rfc5712.txt-
../data/rfc/rfc5712.txt- If more than one soft preempted TE LSP has the same head-end LSR,
--
../data/rfc/rfc5712.txt- transparently.
../data/rfc/rfc5712.txt-
../data/rfc/rfc5712.txt-8. Management
../data/rfc/rfc5712.txt-
../data/rfc/rfc5712.txt- Both the point of preemption and the ingress LER SHOULD provide some
../data/rfc/rfc5712.txt: form of accounting internally and to the network operator interface
../data/rfc/rfc5712.txt- with regard to which TE LSPs and how much capacity is under-
../data/rfc/rfc5712.txt- provisioned due to soft preemption. Displays of under-provisioning
../data/rfc/rfc5712.txt- are recommended for the following midpoint, ingress, and egress
../data/rfc/rfc5712.txt- views:
../data/rfc/rfc5712.txt-
--
../data/rfc/rfc5571.txt- 2. Applicability of L2TPv2 for Softwire Requirements ...............6
../data/rfc/rfc5571.txt- 2.1. Traditional Network Address Translation (NAT and NAPT) .....6
../data/rfc/rfc5571.txt- 2.2. Scalability ................................................7
../data/rfc/rfc5571.txt- 2.3. Routing ....................................................7
../data/rfc/rfc5571.txt- 2.4. Multicast ..................................................7
../data/rfc/rfc5571.txt: 2.5. Authentication, Authorization, and Accounting (AAA) ........7
../data/rfc/rfc5571.txt- 2.6. Privacy, Integrity, and Replay Protection ..................7
../data/rfc/rfc5571.txt- 2.7. Operations and Management ..................................8
../data/rfc/rfc5571.txt- 2.8. Encapsulations .............................................8
../data/rfc/rfc5571.txt- 3. Deployment Scenarios ............................................8
../data/rfc/rfc5571.txt- 3.1. IPv6-over-IPv4 Softwires with L2TPv2 .......................9
--
../data/rfc/rfc5571.txt- 3.2.3. Host behind CPE as Softwire Initiator ..............16
../data/rfc/rfc5571.txt- 3.2.4. Router behind CPE as Softwire Initiator ............16
../data/rfc/rfc5571.txt- 4. References to Standardization Documents ........................17
../data/rfc/rfc5571.txt- 4.1. L2TPv2 ....................................................18
../data/rfc/rfc5571.txt- 4.2. Securing the Softwire Transport ...........................18
../data/rfc/rfc5571.txt: 4.3. Authentication, Authorization, and Accounting .............18
../data/rfc/rfc5571.txt- 4.4. MIB .......................................................18
../data/rfc/rfc5571.txt- 4.5. Softwire Payload Related ..................................19
../data/rfc/rfc5571.txt- 4.5.1. For IPv6 Payloads ..................................19
../data/rfc/rfc5571.txt- 4.5.2. For IPv4 Payloads ..................................19
../data/rfc/rfc5571.txt- 5. Softwire Establishment .........................................20
--
../data/rfc/rfc5571.txt- 8.1.2. IPv4 Softwires .....................................33
../data/rfc/rfc5571.txt- 8.2. Delegated Prefixes ........................................34
../data/rfc/rfc5571.txt- 8.2.1. IPv6 Prefixes ......................................34
../data/rfc/rfc5571.txt- 8.2.2. IPv4 Prefixes ......................................34
../data/rfc/rfc5571.txt- 9. Considerations for Maintenance and Statistics ..................34
../data/rfc/rfc5571.txt: 9.1. RADIUS Accounting .........................................35
../data/rfc/rfc5571.txt- 9.2. MIBs ......................................................35
../data/rfc/rfc5571.txt- 10. Security Considerations .......................................35
../data/rfc/rfc5571.txt- 11. Acknowledgements ..............................................36
../data/rfc/rfc5571.txt- 12. References ....................................................37
../data/rfc/rfc5571.txt- 12.1. Normative References .....................................37
--
../data/rfc/rfc5571.txt-2.4. Multicast
../data/rfc/rfc5571.txt-
../data/rfc/rfc5571.txt- Multicast protocols simply run transparently over L2TPv2 Softwires
../data/rfc/rfc5571.txt- together with other regular IP traffic.
../data/rfc/rfc5571.txt-
../data/rfc/rfc5571.txt:2.5. Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc5571.txt-
../data/rfc/rfc5571.txt- L2TPv2 supports optional mutual Control Channel authentication and
../data/rfc/rfc5571.txt- leverages the optional mutual PPP per-session authentication. L2TPv2
../data/rfc/rfc5571.txt- is well integrated with AAA solutions (such as RADIUS) for both
../data/rfc/rfc5571.txt- authentication and authorization. Most L2TPv2 implementations
../data/rfc/rfc5571.txt- available in the market support the logging of authentication and
../data/rfc/rfc5571.txt- authorization events.
../data/rfc/rfc5571.txt-
../data/rfc/rfc5571.txt: L2TPv2 integration with RADIUS accounting (RADIUS Accounting
../data/rfc/rfc5571.txt- extension for tunnel [RFC2867]) allows the collection and reporting
../data/rfc/rfc5571.txt- of L2TPv2 Softwire usage statistics.
../data/rfc/rfc5571.txt-
../data/rfc/rfc5571.txt-2.6. Privacy, Integrity, and Replay Protection
../data/rfc/rfc5571.txt-
--
../data/rfc/rfc5571.txt-
../data/rfc/rfc5571.txt- RFC 3948 "UDP Encapsulation of IPsec ESP Packets" [RFC3948].
../data/rfc/rfc5571.txt-
../data/rfc/rfc5571.txt- * IPsec supports both IPv4 and IPv6 transports.
../data/rfc/rfc5571.txt-
../data/rfc/rfc5571.txt:4.3. Authentication, Authorization, and Accounting
../data/rfc/rfc5571.txt-
../data/rfc/rfc5571.txt- RFC 2865 "Remote Authentication Dial In User Service (RADIUS)"
../data/rfc/rfc5571.txt- [RFC2865].
../data/rfc/rfc5571.txt-
../data/rfc/rfc5571.txt- * Updated by [RFC2868], [RFC3575], and [RFC5080].
../data/rfc/rfc5571.txt-
../data/rfc/rfc5571.txt: RFC 2867 "RADIUS Accounting Modifications for Tunnel Protocol
../data/rfc/rfc5571.txt- Support" [RFC2867].
../data/rfc/rfc5571.txt-
../data/rfc/rfc5571.txt- RFC 2868 "RADIUS Attributes for Tunnel Protocol Support" [RFC2868].
../data/rfc/rfc5571.txt-
../data/rfc/rfc5571.txt- RFC 3162 "RADIUS and IPv6" [RFC3162].
--
../data/rfc/rfc5571.txt-Storer, et al. Standards Track [Page 34]
../data/rfc/rfc5571.txt-
../data/rfc/rfc5571.txt-RFC 5571 Softwire H & S Framework with L2TPv2 June 2009
../data/rfc/rfc5571.txt-
../data/rfc/rfc5571.txt-
../data/rfc/rfc5571.txt:9.1. RADIUS Accounting
../data/rfc/rfc5571.txt-
../data/rfc/rfc5571.txt: RADIUS Accounting for L2TP and PPP are documented (see Section 4.3).
../data/rfc/rfc5571.txt-
../data/rfc/rfc5571.txt- When deploying Softwire solutions, operators may experience
../data/rfc/rfc5571.txt- difficulties to differentiate the address family of the traffic
../data/rfc/rfc5571.txt: reported in accounting information from RADIUS. This problem and
../data/rfc/rfc5571.txt- some potential solutions are described in [SW-ACCT].
../data/rfc/rfc5571.txt-
../data/rfc/rfc5571.txt-9.2. MIBs
../data/rfc/rfc5571.txt-
../data/rfc/rfc5571.txt- MIB support for L2TPv2 and PPP are documented (see Section 4.4).
--
../data/rfc/rfc5571.txt-Storer, et al. Standards Track [Page 38]
../data/rfc/rfc5571.txt-
../data/rfc/rfc5571.txt-RFC 5571 Softwire H & S Framework with L2TPv2 June 2009
../data/rfc/rfc5571.txt-
../data/rfc/rfc5571.txt-
../data/rfc/rfc5571.txt: [RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting
../data/rfc/rfc5571.txt- Modifications for Tunnel Protocol Support", RFC 2867,
../data/rfc/rfc5571.txt- June 2000.
../data/rfc/rfc5571.txt-
../data/rfc/rfc5571.txt- [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J.,
../data/rfc/rfc5571.txt- Holdrege, M., and I. Goyret, "RADIUS Attributes for
--
../data/rfc/rfc5571.txt- [SUBNET-ALL] Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp,
../data/rfc/rfc5571.txt- "Subnet Allocation Option", Work in Progress,
../data/rfc/rfc5571.txt- March 2009.
../data/rfc/rfc5571.txt-
../data/rfc/rfc5571.txt- [SW-ACCT] Stevant, B., Toutain, L., Dupont, F., and D. Binet,
../data/rfc/rfc5571.txt: "Accounting on Softwires", Work in Progress,
../data/rfc/rfc5571.txt- April 2009.
../data/rfc/rfc5571.txt-
../data/rfc/rfc5571.txt- [SW-SEC] Yamamoto, S., Williams, C., Parent, F., and H. Yokota,
../data/rfc/rfc5571.txt- "Softwire Security Analysis and Requirements", Work
../data/rfc/rfc5571.txt- in Progress, May 2009.
--
../data/rfc/rfc5090.txt- authenticate itself to a proxy server. Digest Authentication is used
../data/rfc/rfc5090.txt- in other protocols as well.
../data/rfc/rfc5090.txt-
../data/rfc/rfc5090.txt- To simplify the provisioning of users, there is a need to support
../data/rfc/rfc5090.txt- this authentication mechanism within Authentication, Authorization,
../data/rfc/rfc5090.txt: and Accounting (AAA) protocols such as RADIUS [RFC2865] and Diameter
../data/rfc/rfc5090.txt- [RFC3588].
../data/rfc/rfc5090.txt-
../data/rfc/rfc5090.txt- This document defines an extension to the RADIUS protocol to enable
../data/rfc/rfc5090.txt- support of Digest Authentication for use with SIP, HTTP, and other
../data/rfc/rfc5090.txt- HTTP-style protocols using this authentication method. Support for
--
../data/rfc/rfc5090.txt- Description
../data/rfc/rfc5090.txt- This attribute describes a protection space component of the
../data/rfc/rfc5090.txt- RADIUS server. HTTP-style protocols differ in their definition
../data/rfc/rfc5090.txt- of the protection space. See [RFC2617], Section 1.2, for
../data/rfc/rfc5090.txt- details. It MUST only be used in Access-Request, Access-
../data/rfc/rfc5090.txt: Challenge, and Accounting-Request packets.
../data/rfc/rfc5090.txt- Type
../data/rfc/rfc5090.txt- 104 for Digest-Realm
../data/rfc/rfc5090.txt- Length
../data/rfc/rfc5090.txt- >= 3
../data/rfc/rfc5090.txt- Text
--
../data/rfc/rfc5090.txt-3.6. Digest-Method Attribute
../data/rfc/rfc5090.txt-
../data/rfc/rfc5090.txt- Description
../data/rfc/rfc5090.txt- This attribute holds the method value to be used in the HTTP
../data/rfc/rfc5090.txt- Digest calculation. This attribute MUST only be used in
../data/rfc/rfc5090.txt: Access-Request and Accounting-Request packets.
../data/rfc/rfc5090.txt- Type
../data/rfc/rfc5090.txt- 108 for Digest-Method
../data/rfc/rfc5090.txt- Length
../data/rfc/rfc5090.txt- >= 3
../data/rfc/rfc5090.txt- Text
--
../data/rfc/rfc5090.txt-3.7. Digest-URI Attribute
../data/rfc/rfc5090.txt-
../data/rfc/rfc5090.txt- Description
../data/rfc/rfc5090.txt- This attribute is used to transport the contents of the
../data/rfc/rfc5090.txt- digest-uri directive or the URI of the HTTP-style request. It
../data/rfc/rfc5090.txt: MUST only be used in Access-Request and Accounting-Request
../data/rfc/rfc5090.txt- packets.
../data/rfc/rfc5090.txt- Type
../data/rfc/rfc5090.txt- 109 for Digest-URI
../data/rfc/rfc5090.txt- Length
../data/rfc/rfc5090.txt- >= 3
--
../data/rfc/rfc5090.txt-
../data/rfc/rfc5090.txt- Description
../data/rfc/rfc5090.txt- This attribute holds the Quality of Protection parameter that
../data/rfc/rfc5090.txt- influences the HTTP Digest calculation. This attribute MUST
../data/rfc/rfc5090.txt- only be used in Access-Request, Access-Challenge, and
../data/rfc/rfc5090.txt: Accounting-Request packets. A RADIUS client SHOULD insert one
../data/rfc/rfc5090.txt- of the Digest-Qop attributes it has received in a previous
../data/rfc/rfc5090.txt- Access-Challenge packet. RADIUS servers SHOULD insert at least
../data/rfc/rfc5090.txt- one Digest-Qop Attribute in an Access-Challenge packet.
../data/rfc/rfc5090.txt- Digest-Qop is optional in order to preserve backward
../data/rfc/rfc5090.txt- compatibility with a minimal implementation of [RFC2069].
--
../data/rfc/rfc5090.txt-3.9. Digest-Algorithm Attribute
../data/rfc/rfc5090.txt-
../data/rfc/rfc5090.txt- Description
../data/rfc/rfc5090.txt- This attribute holds the algorithm parameter that influences
../data/rfc/rfc5090.txt- the HTTP Digest calculation. It MUST only be used in Access-
../data/rfc/rfc5090.txt: Request, Access-Challenge and Accounting-Request packets. If
../data/rfc/rfc5090.txt- this attribute is missing, MD5 is assumed.
../data/rfc/rfc5090.txt- Type
../data/rfc/rfc5090.txt- 111 for Digest-Algorithm
../data/rfc/rfc5090.txt- Length
../data/rfc/rfc5090.txt- >= 3
--
../data/rfc/rfc5090.txt-RFC 5090 RADIUS Extension Digest Authentication February 2008
../data/rfc/rfc5090.txt-
../data/rfc/rfc5090.txt-
../data/rfc/rfc5090.txt- MUST use the User-Name (1) Attribute, and MUST NOT use the
../data/rfc/rfc5090.txt- Digest-Username Attribute. This attribute MUST only be used in
../data/rfc/rfc5090.txt: Access-Request and Accounting-Request packets.
../data/rfc/rfc5090.txt- Type
../data/rfc/rfc5090.txt- 115 for Digest-Username
../data/rfc/rfc5090.txt- Length
../data/rfc/rfc5090.txt- >= 3
../data/rfc/rfc5090.txt- Text
--
../data/rfc/rfc5090.txt-
../data/rfc/rfc5090.txt- the RADIUS implementation MUST repeat this attribute, and each
../data/rfc/rfc5090.txt- instance MUST contain one different unknown Digest
../data/rfc/rfc5090.txt- parameter/value combination. This attribute MUST ONLY be used
../data/rfc/rfc5090.txt- in Access-Request, Access-Challenge, Access-Accept, and
../data/rfc/rfc5090.txt: Accounting-Request packets.
../data/rfc/rfc5090.txt- Type
../data/rfc/rfc5090.txt- 117 for Digest-Auth-Param
../data/rfc/rfc5090.txt- Length
../data/rfc/rfc5090.txt- >= 3
../data/rfc/rfc5090.txt- Text
--
../data/rfc/rfc5090.txt- Challenge packet. The RADIUS client puts them into the quoted,
../data/rfc/rfc5090.txt- space-separated list of URIs of the domain directive of a WWW-
../data/rfc/rfc5090.txt- Authenticate header. Together with Digest-Realm, the URIs in
../data/rfc/rfc5090.txt- the list define the protection space (see [RFC2617], Section
../data/rfc/rfc5090.txt- 3.2.1) for some HTTP-style protocols. This attribute MUST only
../data/rfc/rfc5090.txt: be used in Access-Challenge and Accounting-Request packets.
../data/rfc/rfc5090.txt- Type
../data/rfc/rfc5090.txt- 119 for Digest-Domain
../data/rfc/rfc5090.txt- Length
../data/rfc/rfc5090.txt- 3
../data/rfc/rfc5090.txt-
--
../data/rfc/rfc5090.txt- editorial changes are not mentioned here.
../data/rfc/rfc5090.txt-
../data/rfc/rfc5090.txt- o The Table of Attributes (Section 5) now indicates that the
../data/rfc/rfc5090.txt- Digest-Method Attribute is required within an Access-Request.
../data/rfc/rfc5090.txt- Also, an entry has been added for the State attribute. The table
../data/rfc/rfc5090.txt: also includes entries for Accounting-Request messages. As noted
../data/rfc/rfc5090.txt- in the examples, the User-Name Attribute is not necessary when
../data/rfc/rfc5090.txt- requesting a nonce.
../data/rfc/rfc5090.txt-
../data/rfc/rfc5090.txt- o Two errors in attribute assignment have been corrected within the
../data/rfc/rfc5090.txt- IANA Considerations (Section 7). Digest-Response-Auth is assigned
--
../data/rfc/rfc1299.txt-of changes in service-level reachability in the global TCP/IP Internet.
../data/rfc/rfc1299.txt-This memo provides information for the Internet community. It does not
../data/rfc/rfc1299.txt-specify an Internet standard.
../data/rfc/rfc1299.txt-
../data/rfc/rfc1299.txt-
../data/rfc/rfc1299.txt:1272 Mills Nov 91 Internet Accounting: Background
../data/rfc/rfc1299.txt-
../data/rfc/rfc1299.txt-This document provides background information for the "Internet
../data/rfc/rfc1299.txt:Accounting Architecture". This memo provides information for the
../data/rfc/rfc1299.txt-Internet community. It does not specify an Internet standard.
../data/rfc/rfc1299.txt-
../data/rfc/rfc1299.txt-
../data/rfc/rfc1299.txt-1271 Waldbusser Nov 91 Remote Network Monitoring Management
../data/rfc/rfc1299.txt- Information Base
--
../data/rfc/rfc6065.txt-ISSN: 2070-1721 Elbrys Networks, Inc.
../data/rfc/rfc6065.txt- R. Presuhn, Ed.
../data/rfc/rfc6065.txt- December 2010
../data/rfc/rfc6065.txt-
../data/rfc/rfc6065.txt-
../data/rfc/rfc6065.txt: Using Authentication, Authorization, and Accounting Services
../data/rfc/rfc6065.txt- to Dynamically Provision View-Based Access Control Model
../data/rfc/rfc6065.txt- User-to-Group Mappings
../data/rfc/rfc6065.txt-
../data/rfc/rfc6065.txt-Abstract
../data/rfc/rfc6065.txt-
../data/rfc/rfc6065.txt- This memo defines a portion of the Management Information Base (MIB)
../data/rfc/rfc6065.txt- for use with network management protocols. It describes the use of
../data/rfc/rfc6065.txt: information provided by Authentication, Authorization, and Accounting
../data/rfc/rfc6065.txt- (AAA) services, such as the Remote Authentication Dial-In User
../data/rfc/rfc6065.txt- Service (RADIUS), to dynamically update user-to-group mappings in the
../data/rfc/rfc6065.txt- View-based Access Control Model (VACM).
../data/rfc/rfc6065.txt-
../data/rfc/rfc6065.txt-Status of This Memo
--
../data/rfc/rfc6065.txt-1. Introduction
../data/rfc/rfc6065.txt-
../data/rfc/rfc6065.txt- This memo specifies a way to dynamically provision selected View-
../data/rfc/rfc6065.txt- based Access Control Model (VACM) [RFC3415] Management Information
../data/rfc/rfc6065.txt- Base (MIB) objects, based on information received from an
../data/rfc/rfc6065.txt: Authentication, Authorization, and Accounting (AAA) service, such as
../data/rfc/rfc6065.txt- RADIUS [RFC2865] and [RFC5607]. It reduces the need for security
../data/rfc/rfc6065.txt- administrators to manually update VACM configurations due to user
../data/rfc/rfc6065.txt- churn, allowing a centralized AAA service to provide the information
../data/rfc/rfc6065.txt- associating a given user with the access control policy (known as a
../data/rfc/rfc6065.txt- "group" in VACM) governing that user's access to management
--
../data/rfc/rfc3955.txt-RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt-2.1. CRANE
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt: XACCT's Common Reliable Accounting for Network Element Protocol
../data/rfc/rfc3955.txt- Version 1.0 [7][8] is described as a protocol for the transmission of
../data/rfc/rfc3955.txt: accounting information from "Network Elements" to "mediation" and
../data/rfc/rfc3955.txt- "business support systems".
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt-2.1.1. CRANE Protocol Operation
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- The exporting side is the CRANE client, the collecting side is the
--
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- Diameter [9][10] is an evolution of the Remote Authentication Dial In
../data/rfc/rfc3955.txt- User Service (RADIUS) protocol [22]. RADIUS is widely used to
../data/rfc/rfc3955.txt- outsource authentication and authorization in dialup access
../data/rfc/rfc3955.txt- environments. Diameter is a generalized and extensible protocol
../data/rfc/rfc3955.txt: intended to support Authentication, Authorization and Accounting
../data/rfc/rfc3955.txt- (AAA) requirements of different applications. Dialup and Mobile IPv4
../data/rfc/rfc3955.txt- are examples of such applications defined in the IETF.
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt-2.2.1. Diameter Protocol Operation
../data/rfc/rfc3955.txt-
--
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- LFAP [11][12][13] started out as the "Lightweight Flow Admission
../data/rfc/rfc3955.txt- Protocol" and was used to outsource shortcut creation decisions on
../data/rfc/rfc3955.txt- flow-based routers, as well as to provide per-flow statistics. Later
../data/rfc/rfc3955.txt- versions removed the admission function and changed the name to
../data/rfc/rfc3955.txt: "Lightweight Flow Accounting Protocol".
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt-Leinen Informational [Page 4]
--
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt-2.3.1. LFAP Protocol Operation
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- The exporter in LFAP is called the Connection Control Entity (CCE),
../data/rfc/rfc3955.txt: and the collector is the Flow Accounting Server (FAS). These
../data/rfc/rfc3955.txt- entities communicate with each other over a TCP connection. LFAP
../data/rfc/rfc3955.txt- knows thirteen message types, including operations for connection
../data/rfc/rfc3955.txt- management, version negotiation, flow information messages and
../data/rfc/rfc3955.txt- administrative requests. Authentication and encryption can be
../data/rfc/rfc3955.txt- provided by IPsec or TLS at lower layers. Additionally, the LFAP
--
../data/rfc/rfc3955.txt- authentication and DES-CBC encryption. Note that DES is now widely
../data/rfc/rfc3955.txt- regarded as not adequately secure, because its small key size makes
../data/rfc/rfc3955.txt- brute-force attacks viable.
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- A distinguishing feature is that LFAP has two different message types
../data/rfc/rfc3955.txt: for flow information: A Flow Accounting Request (FAR) message is sent
../data/rfc/rfc3955.txt- when a new flow is identified at the CCE (meter/exporter).
../data/rfc/rfc3955.txt: Accounting information is sent later in one or multiple Flow Update
../data/rfc/rfc3955.txt- Notification (FUN) messages. A collector must match each FUN to a
../data/rfc/rfc3955.txt- Flow ID previously sent in a FAR.
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- The LFAP document also defines a set of useful statistics about the
../data/rfc/rfc3955.txt: accounting process. A separate MIB document [14] is provided for
../data/rfc/rfc3955.txt- management of LFAP entities using SNMP.
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt-2.3.2. LFAP Data Encoding
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- LFAP encodes data in a Type/Length/Value format with four bytes of
--
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt-3.1.1. High-Performance Flow Metering (NetFlow, LFAP)
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- Of the candidate protocols, Cisco's NetFlow is the purest example of
../data/rfc/rfc3955.txt- a highly specialized protocol that has been designed with the sole
../data/rfc/rfc3955.txt: objective of conveying accounting data from flow-aware routers at
../data/rfc/rfc3955.txt: high rates. Starting from a fixed set of accounting fields, it has
../data/rfc/rfc3955.txt- been extended a few times over the years to support additional fields
../data/rfc/rfc3955.txt- and various types of aggregation in the metering/exporting process.
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- Riverstone's LFAP is similarly focused, except that it originated in
../data/rfc/rfc3955.txt- a protocol to outsource the decision whether to create shortcuts in
../data/rfc/rfc3955.txt- flow-based routers. This is still manifest in an increased emphasis
../data/rfc/rfc3955.txt- on reliable operation, and in the split reporting of flow information
../data/rfc/rfc3955.txt: using Flow Accounting Request (FAR) and Flow Update Notification
../data/rfc/rfc3955.txt- (FUN) messages.
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- It has been pointed out that split reporting as done by LFAP can
../data/rfc/rfc3955.txt- reduce memory requirements at the exporter. This concerns a subset
../data/rfc/rfc3955.txt- of attributes that are neither "key" attributes which define flows,
--
../data/rfc/rfc3955.txt- short-lived flows, the number of flow export messages will be
../data/rfc/rfc3955.txt- significantly higher than with "unitary" flow export models, and the
../data/rfc/rfc3955.txt- collector will have to keep state about active flows until they are
../data/rfc/rfc3955.txt- terminated.
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt:3.1.2. Carrier-Grade Multi-Purpose Accounting (IPDR, CRANE)
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- Streaming IPDR and CRANE describe themselves as protocols to
../data/rfc/rfc3955.txt: facilitate the reliable transfer of accounting information between
../data/rfc/rfc3955.txt- Network Elements (or more generally "Service Elements" in the case of
../data/rfc/rfc3955.txt- IPDR) and Mediation Systems or Business Support Systems (BSS). They
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt-
--
../data/rfc/rfc3955.txt-Leinen Informational [Page 7]
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt-RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt: reflect a view of the accounting problem and of network system
../data/rfc/rfc3955.txt- architectures that originates in traditional "vertically integrated"
../data/rfc/rfc3955.txt- telecommunications.
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- Both protocols also emphasize extensibility with the goal of
../data/rfc/rfc3955.txt: applicability to a wide range of accounting tasks.
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- IPDR is based on NDM-U, which uses the XML-Schema language for
../data/rfc/rfc3955.txt: machine-readable specification of accounting data structures, while
../data/rfc/rfc3955.txt- using the efficient XDR encoding for the actual data transfer.
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- CRANE uses templates to describe exported data. These templates are
../data/rfc/rfc3955.txt- negotiated between collector and exporter and can change during a
../data/rfc/rfc3955.txt- session.
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt-3.1.3. General-Purpose AAA (Diameter)
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- Diameter is another example of a broader-purpose protocol, in that it
../data/rfc/rfc3955.txt- covers aspects of authentication and authorization as well as
../data/rfc/rfc3955.txt: accounting. This explains its strong emphasis on security and
../data/rfc/rfc3955.txt- reliability. The design also takes into account various types of
../data/rfc/rfc3955.txt- intermediate agents.
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt-3.2. Data Representation
../data/rfc/rfc3955.txt-
--
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- Diameter has a general capabilities negotiation mechanism. The use
../data/rfc/rfc3955.txt- of Diameter for IPFIX hasn't been described in sufficient detail to
../data/rfc/rfc3955.txt- determine how capabilities negotiation would be used. After
../data/rfc/rfc3955.txt- negotiation, the protocol would operate in essentially unidirectional
../data/rfc/rfc3955.txt: mode, with Accounting-Request (ACR) messages flowing from the
../data/rfc/rfc3955.txt: exporter to the collector, and Accounting-Answer (ACA) messages
../data/rfc/rfc3955.txt- flowing back.
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt-4. Item-Level Compliance Evaluation
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- The template for protocol advocates noted that not all requirements
--
../data/rfc/rfc3955.txt- protocol that supports this.
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt-4.2. Sampling (5.2)
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- CRANE and IPDR don't mention the possibility of sampling. This is
../data/rfc/rfc3955.txt: natural because they are targeted towards telco-grade accounting,
../data/rfc/rfc3955.txt- where sampling would be considered inadmissible. Since support for
../data/rfc/rfc3955.txt- sampling is a "MAY" requirement, its lack could be tolerated, but
../data/rfc/rfc3955.txt- severely restricts the applicability of these protocols in places of
../data/rfc/rfc3955.txt- high aggregation, where absolute precision is not necessary. This
../data/rfc/rfc3955.txt- includes applications such as traffic profiling, traffic engineering,
../data/rfc/rfc3955.txt- and large-scale attack/intrusion detection, but also usage-based
../data/rfc/rfc3955.txt: accounting applications where charging based on sampling is agreed
../data/rfc/rfc3955.txt- upon.
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- The Diameter advocate acknowledges the existence of sampling and
../data/rfc/rfc3955.txt- suggests to define new (grouped) AVPs to carry information about the
../data/rfc/rfc3955.txt- sampling parameters in use.
--
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- Each candidate protocol defines a data model that allows for some
../data/rfc/rfc3955.txt- degree of extensibility.
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- CRANE uses Keys to specify fields in templates. A key "specification
../data/rfc/rfc3955.txt: MUST consist of the description and the data type of the accounting
../data/rfc/rfc3955.txt- item." Apparently extensibility is intended, but it is not clear
../data/rfc/rfc3955.txt- whether adding a new Key really only involves writing a textual
../data/rfc/rfc3955.txt- description and deciding upon a base type. Every Key also has a 32-
../data/rfc/rfc3955.txt- bit Key ID, but from the current specification they don't seem to
../data/rfc/rfc3955.txt- carry global semantics.
--
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt-RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- CRANE, Diameter, and IPDR, as protocols that strive to be carrier-
../data/rfc/rfc3955.txt: grade accounting protocols, understandably exhibit a strong emphasis
../data/rfc/rfc3955.txt- on near-total reliability of the flow export process. All three
../data/rfc/rfc3955.txt- protocols use application-level acknowledgements (in case of IPDR,
../data/rfc/rfc3955.txt- optionally) to include the entire collection process in the feedback
../data/rfc/rfc3955.txt- loop. Indications of "lack of reliability" (lost flow data) are
../data/rfc/rfc3955.txt- somewhat unnatural to these protocols, because they take every effort
--
../data/rfc/rfc3955.txt- where one would rather drop a packet than forward it unaccounted for.
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- LFAP has application-level acknowledgements, and it also reports
../data/rfc/rfc3955.txt- detailed statistics about lost flows and the amount of data that
../data/rfc/rfc3955.txt- couldn't be accounted for. It represents a middle ground in that it
../data/rfc/rfc3955.txt: acknowledges that accounting reliability will sometimes be sacrificed
../data/rfc/rfc3955.txt- for the benefit of other tasks, such as switching packets, and
../data/rfc/rfc3955.txt- provides the tools to gracefully deal with such situations.
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- NetFlow v9 is the only protocol for which the use of a "reliable"
../data/rfc/rfc3955.txt- transport protocol is optional, and the only protocol that doesn't
--
../data/rfc/rfc3955.txt- Status Requests can only be issued by the server (collector), so they
../data/rfc/rfc3955.txt- cannot be used by the server to signal asynchronous events. As in
../data/rfc/rfc3955.txt- IPDR, this could be circumvented by defining templates for meta-
../data/rfc/rfc3955.txt- information.
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt: Diameter could use special Accounting-Request messages for event
../data/rfc/rfc3955.txt- notification.
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- IPDR would presumably define pseudo-"Usage Events" using an XML
../data/rfc/rfc3955.txt- Schema so that events can be reported along with usage data.
../data/rfc/rfc3955.txt-
--
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt-5. Conclusions
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- Every candidate protocol has its strengths and weaknesses. If the
../data/rfc/rfc3955.txt- primary goal of the IPFIX standardization effort were to define a
../data/rfc/rfc3955.txt: carrier-grade accounting protocol that can also be used to carry IP
../data/rfc/rfc3955.txt- flow information, then one of CRANE, Diameter and Streaming IPDR
../data/rfc/rfc3955.txt- would probably be the candidate of choice.
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- But since the goal is to standardize existing practice in the area of
../data/rfc/rfc3955.txt- IP Flow Information Export, it makes sense to analyze why previous
--
../data/rfc/rfc3955.txt- [6] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
../data/rfc/rfc3955.txt- RFC 2409, November 1998.
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt-8.2. Informative References
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt: [7] Zhang, K. and E. Elkin, "XACCT's Common Reliable Accounting for
../data/rfc/rfc3955.txt- Network Element (CRANE) Protocol Specification Version 1.0",
../data/rfc/rfc3955.txt- RFC 3423, November 2002.
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- [8] Zhang, K., "Evaluation of the CRANE Protocol Against IPFIX
../data/rfc/rfc3955.txt- Requirements", Work in Progress, September 2002.
--
../data/rfc/rfc3955.txt- "Diameter Base Protocol", RFC 3588, September 2003.
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- [10] Zander, S., "Evaluation of Diameter Protocol against IPFIX
../data/rfc/rfc3955.txt- Requirements", Work in Progress, September 2002.
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt: [11] Calato, P. and M. MacFaden, "Light-weight Flow Accounting
../data/rfc/rfc3955.txt- Protocol Specification Version 5.0", July 2002.
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt-
--
../data/rfc/rfc3955.txt-Leinen Informational [Page 20]
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt-RFC 3955 Evaluation of Candidate Protocols for IPFIX October 2004
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt: [12] Calato, P. and M. MacFaden, "Light-weight Flow Accounting
../data/rfc/rfc3955.txt- Protocol Data Definition Specification Version 5.0", July 2002.
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- [13] Calato, P., "Evaluation Of Protocol LFAP Against IPFIX
../data/rfc/rfc3955.txt- Requirements", Work in Progress, September 2002.
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt: [14] Calato, P. and M. MacFaden, "Light-weight Flow Accounting
../data/rfc/rfc3955.txt- Protocol MIB", Work in Progress, September 2002.
../data/rfc/rfc3955.txt-
../data/rfc/rfc3955.txt- [15] Claise, B., "Evaluation Of NetFlow Version 9 Against IPFIX
../data/rfc/rfc3955.txt- Requirements", Work in Progress, September 2002.
../data/rfc/rfc3955.txt-
--
../data/rfc/rfc8406.txt-
../data/rfc/rfc8406.txt- Adaptive Linear Coding:
../data/rfc/rfc8406.txt- Linear Coding that utilizes cross-layer adaptation. For instance,
../data/rfc/rfc8406.txt- an adaptive coding scheme may adapt the generation and
../data/rfc/rfc8406.txt- transmission of Repair Packets according to the channel variations
../data/rfc/rfc8406.txt: over time, accounting for the predictive loss of degrees of
../data/rfc/rfc8406.txt- freedom due to erasures.
../data/rfc/rfc8406.txt-
../data/rfc/rfc8406.txt-
../data/rfc/rfc8406.txt-
../data/rfc/rfc8406.txt-
--
../data/rfc/rfc4124.txt- to have different overbooking ratios and simultaneously allows
../data/rfc/rfc4124.txt- overbooking to be tweaked differently (collectively across all CTs)
../data/rfc/rfc4124.txt- on different links. But, in a general sense, it does not allow the
../data/rfc/rfc4124.txt- effective overbooking ratio of every CT to be tweaked differently in
../data/rfc/rfc4124.txt- different parts of the network independently of other CTs, while
../data/rfc/rfc4124.txt: maintaining accurate bandwidth accounting of how different CTs
../data/rfc/rfc4124.txt- mutually affect each other through shared BCs (such as the Maximum
../data/rfc/rfc4124.txt- Reservable Bandwidth).
../data/rfc/rfc4124.txt-
../data/rfc/rfc4124.txt-B.2. Flexibility
../data/rfc/rfc4124.txt-
--
../data/rfc/rfc3693.txt-
../data/rfc/rfc3693.txt- SCENARIO 2: Cell Phone Roaming
../data/rfc/rfc3693.txt-
../data/rfc/rfc3693.txt- In this example, a cell phone is used outside its home service area
../data/rfc/rfc3693.txt- (roaming). Also, the cell phone service provider (cell phone Corp 2)
../data/rfc/rfc3693.txt: outsourced the accounting of cell phone usage. The cell phone is not
../data/rfc/rfc3693.txt- GPS-enabled. Location is derived by the cell phone network in which
../data/rfc/rfc3693.txt- the Target and Device are roaming. When the Target wishes to use the
../data/rfc/rfc3693.txt- cell phone, cell phone Corp 1 (AP) provides the roaming service for
../data/rfc/rfc3693.txt- the Target, which sends the raw data about usage (e.g., duration of
../data/rfc/rfc3693.txt- call, location in the roaming network, etc.) to cell phone Corp 2,
../data/rfc/rfc3693.txt- the home service provider. Cell phone Corp 2 submits the raw data to
../data/rfc/rfc3693.txt: the accounting company, which processes the raw data for the
../data/rfc/rfc3693.txt: accounting statements. Finally, the raw data is sent to a data
../data/rfc/rfc3693.txt- warehouse where the raw data is stored in a Location Server (e.g.,
../data/rfc/rfc3693.txt- computer server).
../data/rfc/rfc3693.txt-
../data/rfc/rfc3693.txt- Cell Phone Corp 1 Cell Phone Corp 2
../data/rfc/rfc3693.txt- ----------------- -----------------
--
../data/rfc/rfc7922.txt- and defines an information model for recording interactions between
../data/rfc/rfc7922.txt- elements implementing the I2RS protocol. This framework provides a
../data/rfc/rfc7922.txt- consistent tracing interface for components implementing the I2RS
../data/rfc/rfc7922.txt- architecture to record what was done, by which component, and when.
../data/rfc/rfc7922.txt- It aims to improve the management of I2RS implementations, and can be
../data/rfc/rfc7922.txt: used for troubleshooting, auditing, forensics, and accounting
../data/rfc/rfc7922.txt- purposes.
../data/rfc/rfc7922.txt-
../data/rfc/rfc7922.txt-Status of This Memo
../data/rfc/rfc7922.txt-
../data/rfc/rfc7922.txt- This document is not an Internet Standards Track specification; it is
--
../data/rfc/rfc7922.txt- from the retained trace logs;
../data/rfc/rfc7922.txt-
../data/rfc/rfc7922.txt- o enhanced network audit, management, and forensic analysis
../data/rfc/rfc7922.txt- capabilities;
../data/rfc/rfc7922.txt-
../data/rfc/rfc7922.txt: o improved accounting of routing system operations; and
../data/rfc/rfc7922.txt-
../data/rfc/rfc7922.txt- o providing a standardized format for incident reporting and test
../data/rfc/rfc7922.txt- logging.
../data/rfc/rfc7922.txt-
../data/rfc/rfc7922.txt-5. Information Model
--
../data/rfc/rfc7922.txt- implements trace log rotation. The details on how this is achieved
../data/rfc/rfc7922.txt- are left to the implementation and are outside the scope of this
../data/rfc/rfc7922.txt- document. However, it should be possible to do a file rotation based
../data/rfc/rfc7922.txt- on either the time or size of the current trace log. If file
../data/rfc/rfc7922.txt- rollover is supported, multiple archived log files should be
../data/rfc/rfc7922.txt: supported in order to maximize the troubleshooting and accounting
../data/rfc/rfc7922.txt- benefits of the trace log.
../data/rfc/rfc7922.txt-
../data/rfc/rfc7922.txt-7.4. Trace Log Retrieval
../data/rfc/rfc7922.txt-
../data/rfc/rfc7922.txt- Implementors are free to provide their own, proprietary interfaces
--
../data/rfc/rfc4925.txt- 2.7. Softwire Concentrator Discovery . . . . . . . . . . . . . 12
../data/rfc/rfc4925.txt- 2.8. Scaling . . . . . . . . . . . . . . . . . . . . . . . . . 12
../data/rfc/rfc4925.txt- 2.9. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 12
../data/rfc/rfc4925.txt- 2.10. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 12
../data/rfc/rfc4925.txt- 2.11. Security . . . . . . . . . . . . . . . . . . . . . . . . . 12
../data/rfc/rfc4925.txt: 2.11.1. Authentication, Authorization, and Accounting
../data/rfc/rfc4925.txt- (AAA) . . . . . . . . . . . . . . . . . . . . . . . . 12
../data/rfc/rfc4925.txt- 2.11.2. Privacy, Integrity, and Replay Protection . . . . . . 13
../data/rfc/rfc4925.txt- 2.12. Operations and Management (OAM) . . . . . . . . . . . . . 13
../data/rfc/rfc4925.txt- 2.13. Encapsulations . . . . . . . . . . . . . . . . . . . . . . 13
../data/rfc/rfc4925.txt- 3. Mesh Problem . . . . . . . . . . . . . . . . . . . . . . . . . 14
--
../data/rfc/rfc4925.txt-
../data/rfc/rfc4925.txt- Softwires must support multicast.
../data/rfc/rfc4925.txt-
../data/rfc/rfc4925.txt-2.11. Security
../data/rfc/rfc4925.txt-
../data/rfc/rfc4925.txt:2.11.1. Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc4925.txt-
../data/rfc/rfc4925.txt- The softwire protocol must support customer authentication in the
../data/rfc/rfc4925.txt- control plane, in order to authorize access to the service, and
../data/rfc/rfc4925.txt: provide adequate logging of activity (accounting). However, a
../data/rfc/rfc4925.txt-
../data/rfc/rfc4925.txt-
../data/rfc/rfc4925.txt-
../data/rfc/rfc4925.txt-Li, et al. Informational [Page 12]
../data/rfc/rfc4925.txt-
--
../data/rfc/rfc4925.txt-
../data/rfc/rfc4925.txt- Other needed OAM features include:
../data/rfc/rfc4925.txt-
../data/rfc/rfc4925.txt- - Logging
../data/rfc/rfc4925.txt-
../data/rfc/rfc4925.txt: - Usage accounting
../data/rfc/rfc4925.txt-
../data/rfc/rfc4925.txt- - End-point failure detection (the detection mechanism must operate
../data/rfc/rfc4925.txt- within the tunnel)
../data/rfc/rfc4925.txt-
../data/rfc/rfc4925.txt- - Path failure detection (the detection mechanism must operate
--
../data/rfc/rfc7069.txt- them. While specific system components might differ between
../data/rfc/rfc7069.txt- implementations, this document details the major components and their
../data/rfc/rfc7069.txt- overall roles in the architecture. To keep the scope narrow, we only
../data/rfc/rfc7069.txt- discuss the primary components related to protocol development.
../data/rfc/rfc7069.txt- Particular deployments will require additional components (e.g.,
../data/rfc/rfc7069.txt: monitoring and accounting at a server), but they are intentionally
../data/rfc/rfc7069.txt- omitted from this document.
../data/rfc/rfc7069.txt-
../data/rfc/rfc7069.txt-
../data/rfc/rfc7069.txt-
../data/rfc/rfc7069.txt-
--
../data/rfc/rfc7069.txt-
../data/rfc/rfc7069.txt- For the list of servers/clients to which data objects have been
../data/rfc/rfc7069.txt- distributed to, the server SHOULD be able to decide on time bounds
../data/rfc/rfc7069.txt- for which this information is stored and specify the corresponding
../data/rfc/rfc7069.txt- time frame in the response to such requests. Some of this
../data/rfc/rfc7069.txt: information may be used for accounting purposes, e.g., the list of
../data/rfc/rfc7069.txt- clients to which data objects have been distributed.
../data/rfc/rfc7069.txt-
../data/rfc/rfc7069.txt: Access information MAY be provided for accounting purposes, for
../data/rfc/rfc7069.txt- example, when uploading DECADE clients are interested in access
../data/rfc/rfc7069.txt: statistics for resources and/or to perform accounting per user.
../data/rfc/rfc7069.txt- Again, access to such information requires client authorization and
../data/rfc/rfc7069.txt- SHOULD be based on the delegation concept as described in
../data/rfc/rfc7069.txt- Section 4.5. The following type of access information elements MAY
../data/rfc/rfc7069.txt- be requested: a) what data objects have been accessed by whom and how
../data/rfc/rfc7069.txt- many times; and b) access tokens that a server has seen for a given
--
../data/rfc/rfc8299.txt- described in Section 1.4.1. Thus, noting the rules set out in
../data/rfc/rfc8299.txt- [RFC7950], it was decided to retain the module name in this document.
../data/rfc/rfc8299.txt-
../data/rfc/rfc8299.txt-2. Acronyms
../data/rfc/rfc8299.txt-
../data/rfc/rfc8299.txt: AAA: Authentication, Authorization, and Accounting.
../data/rfc/rfc8299.txt-
../data/rfc/rfc8299.txt- ACL: Access Control List.
../data/rfc/rfc8299.txt-
../data/rfc/rfc8299.txt- ADSL: Asymmetric DSL.
../data/rfc/rfc8299.txt-
--
../data/rfc/rfc8772.txt-
../data/rfc/rfc8772.txt-2.2. Terms
../data/rfc/rfc8772.txt-
../data/rfc/rfc8772.txt- This section specifies terms used in this document.
../data/rfc/rfc8772.txt-
../data/rfc/rfc8772.txt: AAA: Authentication Authorization Accounting.
../data/rfc/rfc8772.txt-
../data/rfc/rfc8772.txt- ACK: Acknowledgement message.
../data/rfc/rfc8772.txt-
../data/rfc/rfc8772.txt- BAS: Broadband Access Server, also known as a BBRAS, BNG, or
../data/rfc/rfc8772.txt- BRAS.
--
../data/rfc/rfc8772.txt- The rapid development of new services, such as 4K TV, Internet of
../data/rfc/rfc8772.txt- Things (IoT), etc., and increasing numbers of home broadband service
../data/rfc/rfc8772.txt- users present some new challenges for BNGs such as:
../data/rfc/rfc8772.txt-
../data/rfc/rfc8772.txt- Low resource utilization: The traditional BNG acts as both a gateway
../data/rfc/rfc8772.txt: for user access authentication and accounting and also an IP
../data/rfc/rfc8772.txt- network's Layer 3 edge. The mutually affecting nature of the
../data/rfc/rfc8772.txt- tightly coupled control plane and forwarding plane makes it
../data/rfc/rfc8772.txt- difficult to achieve the maximum performance of either plane.
../data/rfc/rfc8772.txt-
../data/rfc/rfc8772.txt- Complex management and maintenance: Due to the large numbers of
--
../data/rfc/rfc8772.txt-
../data/rfc/rfc8772.txt- * Address management: Unified address pool management and CGN
../data/rfc/rfc8772.txt- subscriber address traceability management.
../data/rfc/rfc8772.txt-
../data/rfc/rfc8772.txt- * AAA: This component performs Authentication, Authorization, and
../data/rfc/rfc8772.txt: Accounting, together with RADIUS/Diameter. The BNG communicates
../data/rfc/rfc8772.txt- with the AAA server to check whether the subscriber who sent an
../data/rfc/rfc8772.txt- access request has network access authority. Once the subscriber
../data/rfc/rfc8772.txt- goes online, this component (together with the Service Control
../data/rfc/rfc8772.txt: component) implements accounting, data capacity limitation, and
../data/rfc/rfc8772.txt- QoS enforcement policies.
../data/rfc/rfc8772.txt-
../data/rfc/rfc8772.txt- * Subscriber management: User entry management and forwarding policy
../data/rfc/rfc8772.txt- management.
../data/rfc/rfc8772.txt-
--
../data/rfc/rfc8772.txt- | 4|<--------via Ci---------| |
../data/rfc/rfc8772.txt- | | | |
../data/rfc/rfc8772.txt- | | Create Subscriber | |
../data/rfc/rfc8772.txt- | | Session Response | |
../data/rfc/rfc8772.txt- | 5|---------via Ci-------->| |
../data/rfc/rfc8772.txt: | | | Accounting |
../data/rfc/rfc8772.txt- | | 6|<------------->|
../data/rfc/rfc8772.txt- | | Send Online Response | |
../data/rfc/rfc8772.txt- | 7|<----to UP via Si-------| |
../data/rfc/rfc8772.txt- | | | |
../data/rfc/rfc8772.txt- |Online Response| | |
--
../data/rfc/rfc8772.txt- will be allocated to the subscriber. Policies and security rules
../data/rfc/rfc8772.txt- will be generated for the subscriber. Then the CP sends a request to
../data/rfc/rfc8772.txt- create a session to the UP through the Ci (step 4), and a response is
../data/rfc/rfc8772.txt- expected from the UP to confirm the creation (step 5).
../data/rfc/rfc8772.txt-
../data/rfc/rfc8772.txt: Finally, the CP will notify the AAA server to start accounting (step
../data/rfc/rfc8772.txt- 6). At the same time, an Online Response message (for example, a
../data/rfc/rfc8772.txt- DHCP Ack packet) will be sent to the UP through the Si (step 7). The
../data/rfc/rfc8772.txt- UP will then forward the Online Response to the RG (step 8).
../data/rfc/rfc8772.txt-
../data/rfc/rfc8772.txt- That completes the subscriber activation process.
--
../data/rfc/rfc8772.txt- | | Session Request | |
../data/rfc/rfc8772.txt- | 8|<--------via Ci---------| |
../data/rfc/rfc8772.txt- | | Create Subscriber | |
../data/rfc/rfc8772.txt- | | Session Response | |
../data/rfc/rfc8772.txt- | 9|---------via Ci-------->| |
../data/rfc/rfc8772.txt: | | | Accounting |
../data/rfc/rfc8772.txt- | | 10|<------------->|
../data/rfc/rfc8772.txt- | | Send DHCP ACK | |
../data/rfc/rfc8772.txt- | 11|<----to UP via Si-------| |
../data/rfc/rfc8772.txt- | | | |
../data/rfc/rfc8772.txt- | DHCP ACK | | |
--
../data/rfc/rfc8772.txt- | 8|<--------via Ci-------->| |
../data/rfc/rfc8772.txt- | | | |
../data/rfc/rfc8772.txt- | | Create Subscriber | |
../data/rfc/rfc8772.txt- | | Session Response | |
../data/rfc/rfc8772.txt- | 9|---------via Ci-------->| |
../data/rfc/rfc8772.txt: | | | Accounting |
../data/rfc/rfc8772.txt- | | 10|<------------->|
../data/rfc/rfc8772.txt- | | Send Reply | |
../data/rfc/rfc8772.txt- | 11|<----to UP via Si-------| |
../data/rfc/rfc8772.txt- | Reply | | |
../data/rfc/rfc8772.txt- 12|<--------------| | |
--
../data/rfc/rfc8772.txt- | NS | | |
../data/rfc/rfc8772.txt- 8|-------------->| | |
../data/rfc/rfc8772.txt- | | Relay the Neighbor | |
../data/rfc/rfc8772.txt- | | Solicit (NS) | |
../data/rfc/rfc8772.txt- | 9|-----to CP via Si------>| |
../data/rfc/rfc8772.txt: | | | Accounting |
../data/rfc/rfc8772.txt- | | 10|<------------->|
../data/rfc/rfc8772.txt- | | Send a Neighbor | |
../data/rfc/rfc8772.txt- | | Advertise (NA) | |
../data/rfc/rfc8772.txt- | 11|<----to UP via Si-------| |
../data/rfc/rfc8772.txt- | NA | | |
--
../data/rfc/rfc8772.txt- | 10|<--------via Ci---------| |
../data/rfc/rfc8772.txt- | | | |
../data/rfc/rfc8772.txt- | | Update Subscriber | |
../data/rfc/rfc8772.txt- | | Session Response | |
../data/rfc/rfc8772.txt- | 11|---------via Ci-------->| |
../data/rfc/rfc8772.txt: | | | Accounting |
../data/rfc/rfc8772.txt- | | 12|<------------->|
../data/rfc/rfc8772.txt- | | Send DHCPv6 Reply | |
../data/rfc/rfc8772.txt- | 13|<----to UP via Si-------| |
../data/rfc/rfc8772.txt- | | | |
../data/rfc/rfc8772.txt- | DHCPv6 Reply | | |
--
../data/rfc/rfc8772.txt- | | Session Request | |
../data/rfc/rfc8772.txt- | 8|<--------via Ci-------->| |
../data/rfc/rfc8772.txt- | | Create Subscriber | |
../data/rfc/rfc8772.txt- | | Session Response | |
../data/rfc/rfc8772.txt- | 9|---------via Ci-------->| |
../data/rfc/rfc8772.txt: | | | Accounting |
../data/rfc/rfc8772.txt- | | 10|<------------->|
../data/rfc/rfc8772.txt- | | Send DHCP ACK | |
../data/rfc/rfc8772.txt- | 11|<----to UP via Si-------| |
../data/rfc/rfc8772.txt- | DHCP ACK | | |
../data/rfc/rfc8772.txt- 12|<--------------| | |
--
../data/rfc/rfc8772.txt- | | Session Request | |
../data/rfc/rfc8772.txt- | 22|<--------via Ci---------| |
../data/rfc/rfc8772.txt- | | Update Subscriber | |
../data/rfc/rfc8772.txt- | | Session Response | |
../data/rfc/rfc8772.txt- | 23|---------via Ci-------->| |
../data/rfc/rfc8772.txt: | | | Accounting |
../data/rfc/rfc8772.txt- | | 24|<------------->|
../data/rfc/rfc8772.txt- | | Send DHCPv6 Reply | |
../data/rfc/rfc8772.txt- | 25|<----to UP via Si-------| |
../data/rfc/rfc8772.txt- | DHCPv6 Reply | | |
../data/rfc/rfc8772.txt- 26|<--------------| | |
--
../data/rfc/rfc8772.txt- | | Session Request | |
../data/rfc/rfc8772.txt- | 5|<--------via Ci---------| |
../data/rfc/rfc8772.txt- | | Create Subscriber | |
../data/rfc/rfc8772.txt- | | Session Response | |
../data/rfc/rfc8772.txt- | 6|---------via Ci-------->| |
../data/rfc/rfc8772.txt: | | | Accounting |
../data/rfc/rfc8772.txt- | | 7|<------------->|
../data/rfc/rfc8772.txt- | | | |
../data/rfc/rfc8772.txt-
../data/rfc/rfc8772.txt- Figure 20: IPv4 PPPoE Access
../data/rfc/rfc8772.txt-
--
../data/rfc/rfc8772.txt- | | Session Request | |
../data/rfc/rfc8772.txt- | 8|<--------via Ci---------| |
../data/rfc/rfc8772.txt- | | Update Subscriber | |
../data/rfc/rfc8772.txt- | | Session Response | |
../data/rfc/rfc8772.txt- | 9|---------via Ci-------->| |
../data/rfc/rfc8772.txt: | | | Accounting |
../data/rfc/rfc8772.txt- | | 10|<------------->|
../data/rfc/rfc8772.txt- | DHCPv6 | DHCPv6 | |
../data/rfc/rfc8772.txt- | Negotiation | Negotiation | |
../data/rfc/rfc8772.txt- 7'|<------------->|<---------via Si------->| |
../data/rfc/rfc8772.txt- | | | |
--
../data/rfc/rfc8772.txt- | | Session Request | |
../data/rfc/rfc8772.txt- | 8'|<---------via Ci--------| |
../data/rfc/rfc8772.txt- | | Update Subscriber | |
../data/rfc/rfc8772.txt- | | Session Response | |
../data/rfc/rfc8772.txt- | 9'|---------via Ci-------->| |
../data/rfc/rfc8772.txt: | | | Accounting |
../data/rfc/rfc8772.txt- | | 10'|<------------->|
../data/rfc/rfc8772.txt- | | | |
../data/rfc/rfc8772.txt-
../data/rfc/rfc8772.txt- Figure 21: IPv6 PPPoE Access
../data/rfc/rfc8772.txt-
--
../data/rfc/rfc8772.txt- | | Session Request | |
../data/rfc/rfc8772.txt- | 5|<--------via Ci---------| |
../data/rfc/rfc8772.txt- | | Create v4 Subscriber | |
../data/rfc/rfc8772.txt- | | Session Response | |
../data/rfc/rfc8772.txt- | 6|---------via Ci-------->| |
../data/rfc/rfc8772.txt: | | | Accounting |
../data/rfc/rfc8772.txt- | | 7|<------------->|
../data/rfc/rfc8772.txt- | PPP IP6CP | PPP IP6CP | |
../data/rfc/rfc8772.txt- 4'|<------------->|<---------via Si------->| |
../data/rfc/rfc8772.txt- | | | |
../data/rfc/rfc8772.txt- | | Create V6 Subscriber | |
--
../data/rfc/rfc8772.txt- | | Session Request | |
../data/rfc/rfc8772.txt- | 9|<---------via Ci--------| |
../data/rfc/rfc8772.txt- | | Update v6 Subscriber | |
../data/rfc/rfc8772.txt- | | Session Response | |
../data/rfc/rfc8772.txt- | 10|---------via Ci-------->| |
../data/rfc/rfc8772.txt: | | | Accounting |
../data/rfc/rfc8772.txt- | | 7'|<------------->|
../data/rfc/rfc8772.txt- | DHCPv6 | DHCPv6 | |
../data/rfc/rfc8772.txt- | Negotiation | Negotiation | |
../data/rfc/rfc8772.txt- 8'|<------------->|<---------via Si------->| |
../data/rfc/rfc8772.txt- | | | |
--
../data/rfc/rfc8772.txt- | | Session Request | |
../data/rfc/rfc8772.txt- | 9'|<--------via Ci---------| |
../data/rfc/rfc8772.txt- | | Update v6 Subscriber | |
../data/rfc/rfc8772.txt- | | Session Response | |
../data/rfc/rfc8772.txt- | 10'|---------via Ci-------->| |
../data/rfc/rfc8772.txt: | | | Accounting |
../data/rfc/rfc8772.txt- | | 7"|<------------->|
../data/rfc/rfc8772.txt- | | | |
../data/rfc/rfc8772.txt-
../data/rfc/rfc8772.txt- Figure 22: PPPoE Dual-Stack Access
../data/rfc/rfc8772.txt-
--
../data/rfc/rfc8772.txt- | | | |
../data/rfc/rfc8772.txt- | | Create Subscriber | |
../data/rfc/rfc8772.txt- | | Session Response | |
../data/rfc/rfc8772.txt- | | (with NAT information) | |
../data/rfc/rfc8772.txt- | 9|---------via Ci-------->| |
../data/rfc/rfc8772.txt: | | | Accounting |
../data/rfc/rfc8772.txt- | | | with source |
../data/rfc/rfc8772.txt- | | | information |
../data/rfc/rfc8772.txt- | | 10|<------------->|
../data/rfc/rfc8772.txt- | | | Public IP + |
../data/rfc/rfc8772.txt- | | | Port Range |
--
../data/rfc/rfc8772.txt- might be across the general Internet or other hostile environment.
../data/rfc/rfc8772.txt- The ability of an adversary to block or corrupt messages or introduce
../data/rfc/rfc8772.txt- spurious messages on any one or more of these interfaces would give
../data/rfc/rfc8772.txt- the adversary the ability to stop subscribers from accessing network
../data/rfc/rfc8772.txt- services, disrupt existing subscriber sessions, divert traffic, mess
../data/rfc/rfc8772.txt: up accounting statistics, and generally cause havoc. Damage would
../data/rfc/rfc8772.txt- not necessarily be limited to one or a few subscribers but could
../data/rfc/rfc8772.txt- disrupt routing or deny service to one or more instances of the CP or
../data/rfc/rfc8772.txt- otherwise cause extensive interference. If the adversary knows the
../data/rfc/rfc8772.txt- details of the UP equipment and its forwarding rule capabilities, the
../data/rfc/rfc8772.txt- adversary may be able to cause a copy of most or all user data to be
--
../data/rfc/rfc7211.txt-
../data/rfc/rfc7211.txt- In general, security configuration can be treated as an additional
../data/rfc/rfc7211.txt- configuration item that needs to be set up to establish service.
../data/rfc/rfc7211.txt- There is no significant security value in protecting routing protocol
../data/rfc/rfc7211.txt- keys more than administrative password or Authentication,
../data/rfc/rfc7211.txt: Authorization, and Accounting (AAA) secrets that can be used to gain
../data/rfc/rfc7211.txt- login access to a router. These existing secrets can be used to make
../data/rfc/rfc7211.txt- configuration changes that impact routing protocols as much as
../data/rfc/rfc7211.txt- disclosure of a routing protocol key. Operators already have
../data/rfc/rfc7211.txt- procedures in place for these items. So, it is appropriate to use
../data/rfc/rfc7211.txt- similar procedures for routing protocol keys. It is reasonable to
--
../data/rfc/rfc2567.txt-10.21. END TO END SCENARIO - WITHIN AN ENTERPRISE
../data/rfc/rfc2567.txt-
../data/rfc/rfc2567.txt- An office worker prints on shared departmental printers. All printers
../data/rfc/rfc2567.txt- in the office are public, that is, no authentication or authorization
../data/rfc/rfc2567.txt- is required. Printers are protected from external access by a
../data/rfc/rfc2567.txt: firewall. No billing or accounting is required. Most printing is done
../data/rfc/rfc2567.txt- from desktop applications. A help desk is provided for printing
../data/rfc/rfc2567.txt- problems. Standard operating systems and applications are used.
../data/rfc/rfc2567.txt- Drivers are available, but are installed manually by support
../data/rfc/rfc2567.txt- personnel. This scenario assumes that drivers have been installed and
../data/rfc/rfc2567.txt- that drivers are not IPP aware, that is, they cannot communicate
--
../data/rfc/rfc491.txt-
../data/rfc/rfc491.txt- Now, because of the implementation implications this may all sound
../data/rfc/rfc491.txt- like special pleading, but I claim that another implication of the
../data/rfc/rfc491.txt- "incorrect" formulation will further show the superiority of an
../data/rfc/rfc491.txt- explicit login for mail. For the "loginless" view leads to problems
../data/rfc/rfc491.txt: in regard to the authentication aspects of login and the accounting
../data/rfc/rfc491.txt- aspects, by apparently assuming that the sole purpose of login is to
../data/rfc/rfc491.txt: initiate accounting. In RFC 475, the problem is exposed when, after
../data/rfc/rfc491.txt- noting that some systems allow access control to be applied to
../data/rfc/rfc491.txt- mailboxes, it is asserted that FTP USER command is wrong for access
../data/rfc/rfc491.txt- control because you'd then be on the free account and a new FTP FROM
../data/rfc/rfc491.txt-
../data/rfc/rfc491.txt-
--
../data/rfc/rfc491.txt- list" of the mailbox, and when the mailbox is referenced by a process
../data/rfc/rfc491.txt- the principal identifier of that process must match (explicitly or as
../data/rfc/rfc491.txt- a member of a class) an entry on the list or access will be
../data/rfc/rfc491.txt- forbidden. But the principal identifier is associated with the
../data/rfc/rfc491.txt- process at login. Now, it is probably a valid objection to say that
../data/rfc/rfc491.txt: accounting should be separated from authentification, but it isn't
../data/rfc/rfc491.txt- always. So why invent a redundant mechanism based on the assumption
../data/rfc/rfc491.txt- that it is?
../data/rfc/rfc491.txt-
../data/rfc/rfc491.txt- Another point on authentication via login: it has been argued that
../data/rfc/rfc491.txt- FTP mail ought to be so cheap that it "can be buried in overhead" by
--
../data/rfc/rfc7269.txt-
../data/rfc/rfc7269.txt-5. Source-Address Transparency
../data/rfc/rfc7269.txt-
../data/rfc/rfc7269.txt-5.1. Traceability
../data/rfc/rfc7269.txt-
../data/rfc/rfc7269.txt: Traceability is required in many cases, such as meeting accounting
../data/rfc/rfc7269.txt- requirements and identifying the sources of malicious attacks.
../data/rfc/rfc7269.txt- Operators are asked to record the NAT64 log information for specific
../data/rfc/rfc7269.txt- periods of time. In our lab testing, the log information from
../data/rfc/rfc7269.txt- 200,000 subscribers was collected from a stateful NAT64 gateway for
../data/rfc/rfc7269.txt- 60 days. Syslog [RFC5424] has been adopted to transmit log messages
--
../data/rfc/rfc8158.txt-
../data/rfc/rfc8158.txt- Network operators require NAT devices to log events like creation and
../data/rfc/rfc8158.txt- deletion of translations and information about the resources that the
../data/rfc/rfc8158.txt- NAT device is managing. In many cases, the logs are essential to
../data/rfc/rfc8158.txt- identify an attacker or a host that was used to launch malicious
../data/rfc/rfc8158.txt: attacks and for various other purposes of accounting. Since there is
../data/rfc/rfc8158.txt- no standard way of logging this information, different NAT devices
../data/rfc/rfc8158.txt- use proprietary formats; hence, it is difficult to expect consistent
../data/rfc/rfc8158.txt- behavior. This lack of standardization makes it difficult to write
../data/rfc/rfc8158.txt- the Collector applications that would receive this data and process
../data/rfc/rfc8158.txt- it to present useful information. This document describes the
--
../data/rfc/rfc8158.txt- A Collector may have scale issues if it is overloaded by a large
../data/rfc/rfc8158.txt- number of simultaneous events. An appropriate throttling mechanism
../data/rfc/rfc8158.txt- may be used to handle the oversubscription.
../data/rfc/rfc8158.txt-
../data/rfc/rfc8158.txt- The logs that are exported can be used for a variety of reasons. An
../data/rfc/rfc8158.txt: example use case is to do accounting based on when the users logged
../data/rfc/rfc8158.txt- on and off. The translation will be installed when the user logs on
../data/rfc/rfc8158.txt- and removed when the user logs off. These events create log records.
../data/rfc/rfc8158.txt- Another use case is to identify an attacker or a host in a provider
../data/rfc/rfc8158.txt- network. The network administrators can use these logs to identify
../data/rfc/rfc8158.txt- the usage patterns, the need for additional IP addresses, and etc.
--
../data/rfc/rfc2869.txt- Copyright (C) The Internet Society (2000). All Rights Reserved.
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt-Abstract
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- This document describes additional attributes for carrying
../data/rfc/rfc2869.txt: authentication, authorization and accounting information between a
../data/rfc/rfc2869.txt: Network Access Server (NAS) and a shared Accounting Server using the
../data/rfc/rfc2869.txt- Remote Authentication Dial In User Service (RADIUS) protocol
../data/rfc/rfc2869.txt- described in RFC 2865 [1] and RFC 2866 [2].
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt-Table of Contents
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- 1. Introduction .......................................... 2
../data/rfc/rfc2869.txt- 1.1 Specification of Requirements ................... 3
../data/rfc/rfc2869.txt- 1.2 Terminology ..................................... 3
../data/rfc/rfc2869.txt- 2. Operation ............................................. 4
../data/rfc/rfc2869.txt: 2.1 RADIUS support for Interim Accounting Updates.... 4
../data/rfc/rfc2869.txt- 2.2 RADIUS support for Apple Remote Access
../data/rfc/rfc2869.txt- Protocol ........................................ 5
../data/rfc/rfc2869.txt- 2.3 RADIUS Support for Extensible Authentication
../data/rfc/rfc2869.txt- Protocol (EAP) .................................. 11
../data/rfc/rfc2869.txt- 2.3.1 Protocol Overview ............................... 11
--
../data/rfc/rfc2869.txt- 12. Full Copyright Statement .............................. 47
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt-1. Introduction
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- RFC 2865 [1] describes the RADIUS Protocol as it is implemented and
../data/rfc/rfc2869.txt: deployed today, and RFC 2866 [2] describes how Accounting can be
../data/rfc/rfc2869.txt- performed with RADIUS.
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt-
--
../data/rfc/rfc2869.txt-RFC 2869 RADIUS Extensions June 2000
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- is ended. A user may have multiple sessions in parallel or
../data/rfc/rfc2869.txt- series if the NAS supports that, with each session
../data/rfc/rfc2869.txt: generating a separate start and stop accounting record.
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- silently discard
../data/rfc/rfc2869.txt- This means the implementation discards the packet without
../data/rfc/rfc2869.txt- further processing. The implementation SHOULD provide the
../data/rfc/rfc2869.txt- capability of logging the error, including the contents of
--
../data/rfc/rfc2869.txt-2. Operation
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- Operation is identical to that defined in RFC 2865 [1] and RFC 2866
../data/rfc/rfc2869.txt- [2].
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt:2.1. RADIUS support for Interim Accounting Updates
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- When a user is authenticated, a RADIUS server issues an Access-Accept
../data/rfc/rfc2869.txt- in response to a successful Access-Request. If the server wishes to
../data/rfc/rfc2869.txt: receive interim accounting messages for the given user it must
../data/rfc/rfc2869.txt- include the Acct-Interim-Interval RADIUS attribute in the message,
../data/rfc/rfc2869.txt- which indicates the interval in seconds between interim messages.
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- It is also possible to statically configure an interim value on the
../data/rfc/rfc2869.txt- NAS itself. Note that a locally configured value on the NAS MUST
--
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- Note that all information in an interim message is cumulative (i.e.
../data/rfc/rfc2869.txt- number of packets sent is the total since the beginning of the
../data/rfc/rfc2869.txt- session, not since the last interim message).
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt: It is envisioned that an Interim Accounting record (with Acct-
../data/rfc/rfc2869.txt- Status-Type = Interim-Update (3)) would contain all of the attributes
../data/rfc/rfc2869.txt: normally found in an Accounting Stop message with the exception of
../data/rfc/rfc2869.txt- the Acct-Term-Cause attribute.
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- Since all the information is cumulative, a NAS MUST ensure that only
../data/rfc/rfc2869.txt: a single generation of an interim Accounting message for a given
../data/rfc/rfc2869.txt- session is present in the retransmission queue at any given time.
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt-
--
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt-RFC 2869 RADIUS Extensions June 2000
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- A NAS MAY use a fudge factor to add a random delay between Interim
../data/rfc/rfc2869.txt: Accounting messages for separate sessions. This will ensure that a
../data/rfc/rfc2869.txt- cycle where all messages are sent at once is prevented, such as might
../data/rfc/rfc2869.txt- otherwise occur if a primary link was recently restored and many
../data/rfc/rfc2869.txt- dial-up users were directed to the same NAS at once.
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- The Network and NAS CPU load of using Interim Updates should be
--
../data/rfc/rfc2869.txt- the Access-Request packet, and either NAS-Identifier or NAS-IP-
../data/rfc/rfc2869.txt- Address MUST be included. In order to permit forwarding of the
../data/rfc/rfc2869.txt- Access-Reply by EAP-unaware proxies, if a User-Name attribute was
../data/rfc/rfc2869.txt- included in an Access-Request, the RADIUS Server MUST include the
../data/rfc/rfc2869.txt- User-Name attribute in subsequent Access-Accept packets. Without the
../data/rfc/rfc2869.txt: User-Name attribute, accounting and billing becomes very difficult to
../data/rfc/rfc2869.txt- manage.
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- If identity is determined via another means such as Called-Station-Id
../data/rfc/rfc2869.txt- or Calling-Station-Id, the NAS MUST include these identifying
../data/rfc/rfc2869.txt- attributes in every Access-Request.
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- While this approach will save a round-trip, it cannot be universally
../data/rfc/rfc2869.txt- employed. There are circumstances in which the user's identity may
../data/rfc/rfc2869.txt: not be needed (such as when authentication and accounting is handled
../data/rfc/rfc2869.txt- based on Called-Station-Id or Calling-Station-Id), and therefore an
../data/rfc/rfc2869.txt- EAP-Request/Identity packet may not necessarily be issued by the NAS
../data/rfc/rfc2869.txt- to the authenticating peer. In cases where an EAP-Request/Identity
../data/rfc/rfc2869.txt- packet will not be sent, the NAS will send to the RADIUS server a
../data/rfc/rfc2869.txt- RADIUS Access-Request packet containing an EAP-Message attribute
--
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt-5. Attributes
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- RADIUS Attributes carry the specific authentication, authorization
../data/rfc/rfc2869.txt: and accounting details for the request and response.
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- Some attributes MAY be included more than once. The effect of this
../data/rfc/rfc2869.txt- is attribute specific, and is specified in each attribute
../data/rfc/rfc2869.txt- description. The order of attributes of the same type SHOULD be
../data/rfc/rfc2869.txt- preserved. The order of attributes of different types is not
--
../data/rfc/rfc2869.txt- are reserved for implementation-specific use, and values 241-255
../data/rfc/rfc2869.txt- are reserved and should not be used. This specification concerns
../data/rfc/rfc2869.txt- the following values:
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- 1-39 (refer to RFC 2865 [1], "RADIUS")
../data/rfc/rfc2869.txt: 40-51 (refer to RFC 2866 [2], "RADIUS Accounting")
../data/rfc/rfc2869.txt- 52 Acct-Input-Gigawords
../data/rfc/rfc2869.txt- 53 Acct-Output-Gigawords
../data/rfc/rfc2869.txt- 54 Unused
../data/rfc/rfc2869.txt- 55 Event-Timestamp
../data/rfc/rfc2869.txt- 56-59 Unused
--
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- Description
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- This attribute indicates how many times the Acct-Input-Octets
../data/rfc/rfc2869.txt- counter has wrapped around 2^32 over the course of this service
../data/rfc/rfc2869.txt: being provided, and can only be present in Accounting-Request
../data/rfc/rfc2869.txt- records where the Acct-Status-Type is set to Stop or Interim-
../data/rfc/rfc2869.txt- Update.
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- A summary of the Acct-Input-Gigawords attribute format is shown
../data/rfc/rfc2869.txt- below. The fields are transmitted from left to right.
--
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- Description
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- This attribute indicates how many times the Acct-Output-Octets
../data/rfc/rfc2869.txt- counter has wrapped around 2^32 in the course of delivering this
../data/rfc/rfc2869.txt: service, and can only be present in Accounting-Request records
../data/rfc/rfc2869.txt- where the Acct-Status-Type is set to Stop or Interim-Update.
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- A summary of the Acct-Output-Gigawords attribute format is shown
../data/rfc/rfc2869.txt- below. The fields are transmitted from left to right.
../data/rfc/rfc2869.txt-
--
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt-5.3. Event-Timestamp
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- Description
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt: This attribute is included in an Accounting-Request packet to
../data/rfc/rfc2869.txt- record the time that this event occurred on the NAS, in seconds
../data/rfc/rfc2869.txt- since January 1, 1970 00:00 UTC.
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- A summary of the Event-Timestamp attribute format is shown below.
../data/rfc/rfc2869.txt- The fields are transmitted from left to right.
--
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- This attribute is sent from the NAS to indicate the nature of the
../data/rfc/rfc2869.txt- user's connection.
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- The NAS MAY send this attribute in an Access-Request or
../data/rfc/rfc2869.txt: Accounting-Request to indicate the nature of the user's
../data/rfc/rfc2869.txt- connection.
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- A summary of the Connect-Info attribute format is shown below. The
../data/rfc/rfc2869.txt- fields are transmitted from left to right.
../data/rfc/rfc2869.txt-
--
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- For example, "28800 V42BIS/LAPM" or "52000/31200 V90"
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- More than one Connect-Info attribute may be present in an
../data/rfc/rfc2869.txt: Accounting-Request packet to accommodate expected efforts by ITU
../data/rfc/rfc2869.txt- to have modems report more connection information in a standard
../data/rfc/rfc2869.txt- format that might exceed 252 octets.
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt-5.12. Configuration-Token
../data/rfc/rfc2869.txt-
--
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- Description
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- This Attribute contains a text string which identifies the port of
../data/rfc/rfc2869.txt- the NAS which is authenticating the user. It is only used in
../data/rfc/rfc2869.txt: Access-Request and Accounting-Request packets. Note that this is
../data/rfc/rfc2869.txt- using "port" in its sense of a physical connection on the NAS, not
../data/rfc/rfc2869.txt- in the sense of a TCP or UDP port number.
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- Either NAS-Port or NAS-Port-Id SHOULD be present in an Access-
../data/rfc/rfc2869.txt- Request packet, if the NAS differentiates among its ports. NAS-
--
../data/rfc/rfc2869.txt-5.19. Table of Attributes
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- The following table provides a guide to which attributes may be found
../data/rfc/rfc2869.txt- in which kind of packets. Acct-Input-Gigawords, Acct-Output-
../data/rfc/rfc2869.txt- Gigawords, Event-Timestamp, and NAS-Port-Id may have 0-1 instances in
../data/rfc/rfc2869.txt: an Accounting-Request packet. Connect-Info may have 0+ instances in
../data/rfc/rfc2869.txt: an Accounting-Request packet. The other attributes added in this
../data/rfc/rfc2869.txt: document must not be present in an Accounting-Request.
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt-Request Accept Reject Challenge # Attribute
../data/rfc/rfc2869.txt-0-1 0 0 0 70 ARAP-Password [Note 1]
../data/rfc/rfc2869.txt-0 0-1 0 0-1 71 ARAP-Features
../data/rfc/rfc2869.txt-0 0-1 0 0 72 ARAP-Zone-Access
--
../data/rfc/rfc2869.txt- Message-Authenticator attribute, as described previously.
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt-7.2.3. Man in the middle attacks
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- Since RADIUS security is based on shared secrets, end-to-end security
../data/rfc/rfc2869.txt: is not provided in the case where authentication or accounting
../data/rfc/rfc2869.txt- packets are forwarded along a proxy chain. As a result, attackers
../data/rfc/rfc2869.txt- gaining control of a RADIUS proxy will be able to modify EAP packets
../data/rfc/rfc2869.txt- in transit.
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt-7.2.4. Multiple databases
--
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- [1] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
../data/rfc/rfc2869.txt- Authentication Dial In User Service (RADIUS)", RFC 2865, June
../data/rfc/rfc2869.txt- 2000.
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt: [2] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- [3] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
../data/rfc/rfc2869.txt- Protocol (EAP)", RFC 2284, March 1998.
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
--
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- [6] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and
../data/rfc/rfc2869.txt- I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC
../data/rfc/rfc2869.txt- 2868, June 2000.
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt: [7] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
../data/rfc/rfc2869.txt- Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- [8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
../data/rfc/rfc2869.txt- 2279, January 1998.
../data/rfc/rfc2869.txt-
--
../data/rfc/rfc2869.txt- [11] Slatalla, M., and Quittner, J., "Masters of Deception."
../data/rfc/rfc2869.txt- HarperCollins, New York, 1995.
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt-9. Acknowledgements
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt: RADIUS and RADIUS Accounting were originally developed by Livingston
../data/rfc/rfc2869.txt- Enterprises (now part of Lucent Technologies) for their PortMaster
../data/rfc/rfc2869.txt- series of Network Access Servers.
../data/rfc/rfc2869.txt-
../data/rfc/rfc2869.txt- The section on ARAP is adopted with permission from "Using RADIUS to
../data/rfc/rfc2869.txt- Authenticate Apple Remote Access Connections" by Ward Willats of Cyno
--
../data/rfc/rfc6127.txt- private addresses [IPv4-SPACE-ISSUES].
../data/rfc/rfc6127.txt-
../data/rfc/rfc6127.txt- Network operations that had previously been tied to a single IPv4
../data/rfc/rfc6127.txt- address for a subscriber would need to be considered when deploying
../data/rfc/rfc6127.txt- NAT444 as well. These may include troubleshooting, operations,
../data/rfc/rfc6127.txt: accounting, logging and legal intercept, Quality of Service (QoS)
../data/rfc/rfc6127.txt- functions, anti-spoofing and security, backoffice systems, etc.
../data/rfc/rfc6127.txt- Ironically, some of these considerations overlap with the kinds of
../data/rfc/rfc6127.txt- considerations one needs to perform when deploying IPv6.
../data/rfc/rfc6127.txt-
../data/rfc/rfc6127.txt- Consequences aside, NAT444 service is already being deployed in some
--
../data/rfc/rfc1009.txt- respect to the ISO connectionless network model and incorporate
../data/rfc/rfc1009.txt- defined packet formats, routing algorithms and related procedures
../data/rfc/rfc1009.txt- [33, 34]. The ISO ES-IS [37] provides the functions of ARP and
../data/rfc/rfc1009.txt- ICMP Redirect.
../data/rfc/rfc1009.txt-
../data/rfc/rfc1009.txt: B.5. Access Control and Accounting
../data/rfc/rfc1009.txt-
../data/rfc/rfc1009.txt- There are no requirements for NSF gateways at this time to
../data/rfc/rfc1009.txt: incorporate specific access-control and accounting mechanisms in
../data/rfc/rfc1009.txt- the design; however, these important issues are currently under
../data/rfc/rfc1009.txt- study and will be incorporated into a subsequent edition of this
../data/rfc/rfc1009.txt- document. Vendors are encouraged to plan for the introduction of
../data/rfc/rfc1009.txt- these mechanisms into their products. While at this time no
../data/rfc/rfc1009.txt: definitive common model for access control and accounting has
../data/rfc/rfc1009.txt- emerged, it is possible to outline some general features such a
../data/rfc/rfc1009.txt- model is likely to have, among them the following:
../data/rfc/rfc1009.txt-
../data/rfc/rfc1009.txt-
../data/rfc/rfc1009.txt-
--
../data/rfc/rfc1009.txt-
../data/rfc/rfc1009.txt-
../data/rfc/rfc1009.txt-RFC 1009 - Requirements for Internet Gateways June 1987
../data/rfc/rfc1009.txt-
../data/rfc/rfc1009.txt-
../data/rfc/rfc1009.txt: 1. The primary access control and accounting mechanisms will
../data/rfc/rfc1009.txt- be in the service hosts themselves, not the gateways,
../data/rfc/rfc1009.txt- packet-switches or workstations.
../data/rfc/rfc1009.txt-
../data/rfc/rfc1009.txt: 2. Agents acting on behalf of access control and accounting
../data/rfc/rfc1009.txt- mechanisms may be necessary in the gateways, to collect
../data/rfc/rfc1009.txt- data, enforce password protection, or mitigate resource
../data/rfc/rfc1009.txt- priority and fairness. However, the architecture and
../data/rfc/rfc1009.txt- protocols used by these agents may be a local matter and
../data/rfc/rfc1009.txt- cannot be specified in advance.
../data/rfc/rfc1009.txt-
../data/rfc/rfc1009.txt- 3. NSF gateways may be required to incorporate access control
../data/rfc/rfc1009.txt: and accounting mechanisms based on datagram
../data/rfc/rfc1009.txt- source/destination address, as well as other fields in the
../data/rfc/rfc1009.txt- IP header.
../data/rfc/rfc1009.txt-
../data/rfc/rfc1009.txt- 4. NSF gateways may be required to enforce policies on access
../data/rfc/rfc1009.txt- to gateway and communication resources. These policies may
--
../data/rfc/rfc6646.txt-5.1. Denial-of-Service Attacks
../data/rfc/rfc6646.txt-
../data/rfc/rfc6646.txt- An attacker can try to consume a large portion of the in-network
../data/rfc/rfc6646.txt- storage, or exhaust the connections of the in-network storage through
../data/rfc/rfc6646.txt- a denial-of-service (DoS) attack. Authentication, authorization, and
../data/rfc/rfc6646.txt: accounting mechanisms should be considered in the cross-domain
../data/rfc/rfc6646.txt- environment. Limitation of access from an administrative domain sets
../data/rfc/rfc6646.txt- up barriers for content distribution.
../data/rfc/rfc6646.txt-
../data/rfc/rfc6646.txt-5.2. Copyright and Legal Issues
../data/rfc/rfc6646.txt-
--
../data/rfc/rfc3084.txt- 5. COPS-PR Client-Specific Data Formats............................23
../data/rfc/rfc3084.txt- 5.1. Named Decision Data...........................................23
../data/rfc/rfc3084.txt- 5.2. ClientSI Request Data.........................................24
../data/rfc/rfc3084.txt- 5.3. Policy Provisioning Report Data...............................24
../data/rfc/rfc3084.txt- 5.3.1. Success and Failure Report-Type Data Format.................24
../data/rfc/rfc3084.txt: 5.3.2. Accounting Report-Type Data Format..........................25
../data/rfc/rfc3084.txt- 6. Common Operation................................................26
../data/rfc/rfc3084.txt- 7. Fault Tolerance.................................................28
../data/rfc/rfc3084.txt- 8. Security Considerations.........................................29
../data/rfc/rfc3084.txt- 9. IANA Considerations.............................................29
../data/rfc/rfc3084.txt- 10. Acknowledgements...............................................30
--
../data/rfc/rfc3084.txt- the action taken.
../data/rfc/rfc3084.txt-
../data/rfc/rfc3084.txt-3.3. Report State (RPT) PEP -> PDP
../data/rfc/rfc3084.txt-
../data/rfc/rfc3084.txt- The RPT message is sent from the policy provisioning clients to the
../data/rfc/rfc3084.txt: PDP to report accounting information associated with the provisioned
../data/rfc/rfc3084.txt- policy, or to notify the PDP of changes in the PEP (Report-Type = '
../data/rfc/rfc3084.txt: Accounting') related to the provisioning client.
../data/rfc/rfc3084.txt-
../data/rfc/rfc3084.txt- RPT is also used as a mechanism to inform the PDP about the action
../data/rfc/rfc3084.txt- taken at the PEP in response to a DEC message. For example, in
../data/rfc/rfc3084.txt- response to an 'Install' decision, the PEP informs the PDP if the
../data/rfc/rfc3084.txt- policy data is installed (Report-Type = 'Success') or not (Report-
--
../data/rfc/rfc3084.txt- always respond to a DEC with a solicited RPT even in response to a
../data/rfc/rfc3084.txt- NULL DEC, in which case the Report-Type will be 'Success'.
../data/rfc/rfc3084.txt-
../data/rfc/rfc3084.txt- Reports can also be unsolicited and all unsolicited Reports MUST NOT
../data/rfc/rfc3084.txt- set the solicited message flag in their COPS message header. Examples
../data/rfc/rfc3084.txt: of unsolicited reports include 'Accounting' Report-Types, which were
../data/rfc/rfc3084.txt- not triggered by a specific DEC messages, or 'Failure' Report-Types,
../data/rfc/rfc3084.txt- which indicate a failure in a previously successfully installed
../data/rfc/rfc3084.txt- configuration (note that, in the case of such unsolicited failures,
../data/rfc/rfc3084.txt- the PEP cannot rollback to a previous "good" state as it becomes
../data/rfc/rfc3084.txt- ambiguous under these asynchronous conditions what the correct state
--
../data/rfc/rfc3084.txt-
../data/rfc/rfc3084.txt-RFC 3084 COPS-PR March 2001
../data/rfc/rfc3084.txt-
../data/rfc/rfc3084.txt-
../data/rfc/rfc3084.txt- The RPT message may contain provisioning client information such as
../data/rfc/rfc3084.txt: accounting parameters or errors/warnings related to a decision. The
../data/rfc/rfc3084.txt- data format for this information is defined in the context of the
../data/rfc/rfc3084.txt- policy information base (see section 5). The RPT message has the
../data/rfc/rfc3084.txt- following format:
../data/rfc/rfc3084.txt-
../data/rfc/rfc3084.txt- <Report State> ::= <Common Header>
--
../data/rfc/rfc3084.txt- conjunction with the accompanying COPS Report Type object to
../data/rfc/rfc3084.txt- encapsulate COPS-PR report information from the PEP to the PDP.
../data/rfc/rfc3084.txt- Report types can be 'Success' or 'Failure', indicating to the PDP
../data/rfc/rfc3084.txt- that a particular set of provisioning policies has been either
../data/rfc/rfc3084.txt- successfully or unsuccessfully installed/removed on the PEP, or
../data/rfc/rfc3084.txt: 'Accounting'.
../data/rfc/rfc3084.txt-
../data/rfc/rfc3084.txt-5.3.1. Success and Failure Report-Type Data Format
../data/rfc/rfc3084.txt-
../data/rfc/rfc3084.txt- Report-types can be 'Success' or 'Failure' indicating to the PDP that
../data/rfc/rfc3084.txt- a particular set of provisioning policies has been either
--
../data/rfc/rfc3084.txt-
../data/rfc/rfc3084.txt- <Named ClientSI: Report> ::= <[<GPERR>] *(<report>)>
../data/rfc/rfc3084.txt-
../data/rfc/rfc3084.txt- <report> ::= <ErrorPRID> <CPERR> *(<PRID><EPD>)
../data/rfc/rfc3084.txt-
../data/rfc/rfc3084.txt:5.3.2. Accounting Report-Type Data Format
../data/rfc/rfc3084.txt-
../data/rfc/rfc3084.txt: Additionally, reports can be used to carry accounting information
../data/rfc/rfc3084.txt: when specifying the 'Accounting' Report-Type. This accounting report
../data/rfc/rfc3084.txt- message will typically carry statistical or event information related
../data/rfc/rfc3084.txt- to the installed configuration for use at the PDP. This information
../data/rfc/rfc3084.txt- is encoded as one or more <PRID><EPD> bindings that generally
../data/rfc/rfc3084.txt: describe the accounting information being reported from the PEP to
../data/rfc/rfc3084.txt- the PDP.
../data/rfc/rfc3084.txt-
../data/rfc/rfc3084.txt- The format for this data is encapsulated in the COPS Named ClientSI
../data/rfc/rfc3084.txt- object as follows:
../data/rfc/rfc3084.txt-
../data/rfc/rfc3084.txt- <Named ClientSI: Report> ::= <*(<PRID><EPD>)>
../data/rfc/rfc3084.txt-
../data/rfc/rfc3084.txt: NOTE: RFC 2748 defines an optional Accounting-Timer (AcctTimer)
../data/rfc/rfc3084.txt- object for use in the COPS Client-Accept message. Periodic
../data/rfc/rfc3084.txt: accounting reports for COPS-PR clients are also obligated to be paced
../data/rfc/rfc3084.txt: by this timer. Periodic accounting reports SHOULD NOT be generated
../data/rfc/rfc3084.txt- by the PEP more frequently than the period specified by the COPS
../data/rfc/rfc3084.txt: AcctTimer. Thus, the period between new accounting reports SHOULD be
../data/rfc/rfc3084.txt- greater-than or equal-to the period specified (if specified) in the
../data/rfc/rfc3084.txt- AcctTimer. If no AcctTimer object is specified by the PDP, then
../data/rfc/rfc3084.txt: there are no constraints imposed on the PEP's accounting interval.
../data/rfc/rfc3084.txt-
../data/rfc/rfc3084.txt-
../data/rfc/rfc3084.txt-
../data/rfc/rfc3084.txt-
../data/rfc/rfc3084.txt-
--
../data/rfc/rfc3084.txt- its previously installed (good) state as if the DEC never occurred.
../data/rfc/rfc3084.txt- The PDP is then free to modify its decision and try again.
../data/rfc/rfc3084.txt-
../data/rfc/rfc3084.txt- The PEP can report to the PDP the current status of any installed
../data/rfc/rfc3084.txt- request state when appropriate. This information is sent in a
../data/rfc/rfc3084.txt: Report-State (RPT) message with the "Accounting" flag set. The
../data/rfc/rfc3084.txt- request state that is being reported is identified via the associated
../data/rfc/rfc3084.txt- Client Handle in the report message.
../data/rfc/rfc3084.txt-
../data/rfc/rfc3084.txt- Finally, Client-Close (CC) messages are used to cancel the
../data/rfc/rfc3084.txt- corresponding Client-Open message. The CC message informs the other
--
../data/rfc/rfc4847.txt-
../data/rfc/rfc4847.txt- - Reception of connection information: Customers MAY be allowed to
../data/rfc/rfc4847.txt- receive information for current VPN connections (through the
../data/rfc/rfc4847.txt- management plane).
../data/rfc/rfc4847.txt-
../data/rfc/rfc4847.txt: - Reception of accounting information: Customers MUST be able to
../data/rfc/rfc4847.txt: receive accounting information for each VPN.
../data/rfc/rfc4847.txt-
../data/rfc/rfc4847.txt- - Specification of policy: Customers MAY be allowed to specify
../data/rfc/rfc4847.txt- policies (e.g., path computation policies, recovery policies
../data/rfc/rfc4847.txt- including parameters) for each VPN.
../data/rfc/rfc4847.txt-
--
../data/rfc/rfc4847.txt- documents, such as [RFC3945]. Also, manageability considerations for
../data/rfc/rfc4847.txt- L3VPN are described in existing documents, such as [RFC4176]. These
../data/rfc/rfc4847.txt- manageability considerations should also be applied in L1VPNs, and
../data/rfc/rfc4847.txt- these aspects are described in this section. In addition, there are
../data/rfc/rfc4847.txt- some specific manageability considerations for L1VPNs, such as
../data/rfc/rfc4847.txt: configuration and accounting.
../data/rfc/rfc4847.txt-
../data/rfc/rfc4847.txt- o Fault management
../data/rfc/rfc4847.txt-
../data/rfc/rfc4847.txt- The provider network MUST support fault management. It MUST support
../data/rfc/rfc4847.txt- liveness detection, and monitoring and verification of correct
--
../data/rfc/rfc4847.txt- configuration.
../data/rfc/rfc4847.txt-
../data/rfc/rfc4847.txt- It SHOULD be possible for the provider network to verify that
../data/rfc/rfc4847.txt- configuration is correctly made.
../data/rfc/rfc4847.txt-
../data/rfc/rfc4847.txt: o Accounting management
../data/rfc/rfc4847.txt-
../data/rfc/rfc4847.txt: The provider network MUST support accounting management. It MUST
../data/rfc/rfc4847.txt- be able to record usage of VPN connections for each customer.
../data/rfc/rfc4847.txt-
../data/rfc/rfc4847.txt- o Performance management
../data/rfc/rfc4847.txt-
../data/rfc/rfc4847.txt- The provider network MUST support performance management.
--
../data/rfc/rfc5627.txt-
../data/rfc/rfc5627.txt- If a proxy is in either the originating or terminating domains but is
../data/rfc/rfc5627.txt- not an authoritative proxy, the proxy MAY record-route.
../data/rfc/rfc5627.txt-
../data/rfc/rfc5627.txt- If a proxy in the terminating domain requires mid-dialog requests to
../data/rfc/rfc5627.txt: pass through it for whatever reason (firewall traversal, accounting,
../data/rfc/rfc5627.txt- etc.), the proxy MUST still record-route, and MUST NOT assume that a
../data/rfc/rfc5627.txt- UA will utilize its GRUU in the Contact header field of its response
../data/rfc/rfc5627.txt- (which would cause mid-dialog requests to pass through the proxy
../data/rfc/rfc5627.txt- without record-routing).
../data/rfc/rfc5627.txt-
--
../data/rfc/rfc2721.txt-
../data/rfc/rfc2721.txt- The RTFM Traffic Measurement System has been developed by the
../data/rfc/rfc2721.txt- Realtime Traffic Flow Measurement Working Group. It is described in
../data/rfc/rfc2721.txt- six other documents, as follows:
../data/rfc/rfc2721.txt-
../data/rfc/rfc2721.txt: [ACT-BKG] Internet Accounting: Background (Informational)
../data/rfc/rfc2721.txt-
../data/rfc/rfc2721.txt- Sets out the requirements for a usage reporting system for network
../data/rfc/rfc2721.txt- traffic. Sketches out the RTFM Architecture (meters, meter
../data/rfc/rfc2721.txt- readers and managers) allowing for multiple meters and meter
../data/rfc/rfc2721.txt- readers, with asynchronous reading from the meters. Proposes
--
../data/rfc/rfc2721.txt- much data reduction work as possible, which minimizes the amount of
../data/rfc/rfc2721.txt- data to be read and the amount of processing needed to produce useful
../data/rfc/rfc2721.txt- reports from it.
../data/rfc/rfc2721.txt-
../data/rfc/rfc2721.txt- RTFM flow data can be used for a wide range of purposes, such as
../data/rfc/rfc2721.txt: usage accounting, long-term recording of network usage (classified by
../data/rfc/rfc2721.txt- IP address attributes) and real-time analysis of traffic flows at
../data/rfc/rfc2721.txt- remote metering points.
../data/rfc/rfc2721.txt-
../data/rfc/rfc2721.txt-3 Applicability Statement (AS)
../data/rfc/rfc2721.txt-
--
../data/rfc/rfc2721.txt-
../data/rfc/rfc2721.txt- provides a very effective way to read flow data from a traffic meter.
../data/rfc/rfc2721.txt-
../data/rfc/rfc2721.txt-9 References
../data/rfc/rfc2721.txt-
../data/rfc/rfc2721.txt: [ACT-BKG] Mills, C., Hirsch, G. and G. Ruth, "Internet Accounting
../data/rfc/rfc2721.txt- Background", RFC 1272, November 1991.
../data/rfc/rfc2721.txt-
../data/rfc/rfc2721.txt- [RTFM-ARC] Brownlee, N., Mills, C. and G. Ruth, "Traffic Flow
../data/rfc/rfc2721.txt- Measurement: Architecture", RFC 2722, October 1999.
../data/rfc/rfc2721.txt-
--
../data/rfc/rfc5757.txt- denial-of-service attacks. In addition to source authentication, a
../data/rfc/rfc5757.txt- rate control of the replicator may be required to protect the agent
../data/rfc/rfc5757.txt- and the downstream network.
../data/rfc/rfc5757.txt-
../data/rfc/rfc5757.txt- Mobility protocols need to consider the implications and requirements
../data/rfc/rfc5757.txt: for Authentication, Authorization, and Accounting (AAA). An MN may
../data/rfc/rfc5757.txt- have been authorized to receive a specific multicast group when using
../data/rfc/rfc5757.txt- one mobile network, but this may not be valid when attaching to a
../data/rfc/rfc5757.txt- different network. In general, the AAA association for an MN may
../data/rfc/rfc5757.txt- change between attachments, or may be individually chosen prior to
../data/rfc/rfc5757.txt- network (re-)association. The most appropriate network path may be
--
../data/rfc/rfc7241.txt-4.3. Solicited Review Processes
../data/rfc/rfc7241.txt-
../data/rfc/rfc7241.txt- With the number of areas of cooperation between IEEE 802 and IETF
../data/rfc/rfc7241.txt- increasing, the document review process has extended beyond the
../data/rfc/rfc7241.txt- traditional subjects of SMI (Structure of Management Information) MIB
../data/rfc/rfc7241.txt: modules and AAA (Authentication, Authorization, and Accounting)
../data/rfc/rfc7241.txt- described in [RFC4441]. IESG members routinely solicit directorate
../data/rfc/rfc7241.txt- reviews as a means to request the opinion of specialized experts on
../data/rfc/rfc7241.txt- specific aspects of documents in IESG review (examples include
../data/rfc/rfc7241.txt- security, "MIB Doctors", or congestion management reviews). Area
../data/rfc/rfc7241.txt- Directors may also require solicited reviews from IEEE 802 or IEEE
--
../data/rfc/rfc7241.txt-
../data/rfc/rfc7241.txt- Heard, C., Ed., "RFC 4181 Update to Recognize the IETF
../data/rfc/rfc7241.txt- Trust", BCP 111, RFC 4841, March 2007.
../data/rfc/rfc7241.txt-
../data/rfc/rfc7241.txt- [BCP132] Housley, R. and B. Aboba, "Guidance for Authentication,
../data/rfc/rfc7241.txt: Authorization, and Accounting (AAA) Key Management", BCP
../data/rfc/rfc7241.txt- 132, RFC 4962, July 2007.
../data/rfc/rfc7241.txt-
../data/rfc/rfc7241.txt- [BCP158] DeKok, A., Ed., and G. Weber, "RADIUS Design Guidelines",
../data/rfc/rfc7241.txt- BCP 158, RFC 6158, March 2011.
../data/rfc/rfc7241.txt-
--
../data/rfc/rfc7241.txt-A.2. AAA Review
../data/rfc/rfc7241.txt-
../data/rfc/rfc7241.txt- IEEE 802 WGs requiring new AAA applications should send a liaison
../data/rfc/rfc7241.txt- request to the IETF. Where new attribute definitions are sufficient,
../data/rfc/rfc7241.txt- rather than defining new authentication, authorization, and
../data/rfc/rfc7241.txt: accounting logic and procedures, an Internet-Draft can be submitted
../data/rfc/rfc7241.txt- and review can be requested from AAA-related WGs such as the RADEXT
../data/rfc/rfc7241.txt- or DIME WGs.
../data/rfc/rfc7241.txt-
../data/rfc/rfc7241.txt- In addition to the RADEXT and DIME WGs, a "AAA doctors" team
../data/rfc/rfc7241.txt- (directorate) is currently active in the OPS Area and can be
--
../data/rfc/rfc8167.txt-4.1. Reverse-Direction Credits
../data/rfc/rfc8167.txt-
../data/rfc/rfc8167.txt- RPC-over-RDMA credits work the same way in the reverse direction as
../data/rfc/rfc8167.txt- they do in the forward direction. However, forward-direction credits
../data/rfc/rfc8167.txt- and reverse-direction credits on the same connection are accounted
../data/rfc/rfc8167.txt: separately. Direction-independent credit accounting prevents head-
../data/rfc/rfc8167.txt- of-line blocking in one direction from impacting operation in the
../data/rfc/rfc8167.txt- other direction.
../data/rfc/rfc8167.txt-
../data/rfc/rfc8167.txt- The forward-direction credit value retains the same meaning whether
../data/rfc/rfc8167.txt- or not there are reverse-direction resources associated with an RPC-
--
../data/rfc/rfc8568.txt- if each data center is protected separately via firewalls,
../data/rfc/rfc8568.txt- Demilitarized Zones (DMZs), and other network-protection techniques.
../data/rfc/rfc8568.txt-
../data/rfc/rfc8568.txt- SDN can also be used to help improve security by facilitating the
../data/rfc/rfc8568.txt- operation of existing protocols, such as Authentication,
../data/rfc/rfc8568.txt: Authorization and Accounting (AAA). The management of AAA
../data/rfc/rfc8568.txt- infrastructures, namely the management of AAA routing and the
../data/rfc/rfc8568.txt- establishment of security associations between AAA entities, can be
../data/rfc/rfc8568.txt- performed using SDN, as analyzed in [SDN-AAA].
../data/rfc/rfc8568.txt-
../data/rfc/rfc8568.txt-4.9. Separation of Control Concerns
--
../data/rfc/rfc6787.txt- rules in the HTTP/1.1 specification [RFC2616] and append the "Age"
../data/rfc/rfc6787.txt- attribute accordingly. This attribute is provided because time may
../data/rfc/rfc6787.txt- have passed since the client received the cookie from an HTTP server.
../data/rfc/rfc6787.txt- Rather than having the client reduce Max-Age by the actual age, it
../data/rfc/rfc6787.txt- passes Max-Age verbatim and appends the "Age" attribute, thus
../data/rfc/rfc6787.txt: maintaining the cookie as received while still accounting for the
../data/rfc/rfc6787.txt- fact that time has passed.
../data/rfc/rfc6787.txt-
../data/rfc/rfc6787.txt- The MRCPv2 client or server MUST supply defaults for the "Domain" and
../data/rfc/rfc6787.txt- "Path" attributes, as specified in RFC 6265, if they are omitted by
../data/rfc/rfc6787.txt- the HTTP origin server. Note that there is no leading dot present in
--
../data/rfc/rfc3376.txt- the reasons behind this decision.
../data/rfc/rfc3376.txt-
../data/rfc/rfc3376.txt- 1. Routers may want to track per-host membership status on an
../data/rfc/rfc3376.txt- interface. This allows routers to implement fast leaves (e.g.,
../data/rfc/rfc3376.txt- for layered multicast congestion control schemes) as well as track
../data/rfc/rfc3376.txt: membership status for possible accounting purposes.
../data/rfc/rfc3376.txt-
../data/rfc/rfc3376.txt- 2. Membership Report suppression does not work well on bridged LANs.
../data/rfc/rfc3376.txt- Many bridges and Layer2/Layer3 switches that implement IGMP
../data/rfc/rfc3376.txt- snooping do not forward IGMP messages across LAN segments in order
../data/rfc/rfc3376.txt- to prevent membership report suppression. Removing membership
--
../data/rfc/rfc3957.txt-Category: Standards Track P. Calhoun
../data/rfc/rfc3957.txt- Airespace
../data/rfc/rfc3957.txt- March 2005
../data/rfc/rfc3957.txt-
../data/rfc/rfc3957.txt-
../data/rfc/rfc3957.txt: Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc3957.txt- Registration Keys for Mobile IPv4
../data/rfc/rfc3957.txt-
../data/rfc/rfc3957.txt-Status of this Memo
../data/rfc/rfc3957.txt-
../data/rfc/rfc3957.txt- This document specifies an Internet standards track protocol for the
--
../data/rfc/rfc3957.txt-
../data/rfc/rfc3957.txt- Copyright (C) The Internet Society (2005).
../data/rfc/rfc3957.txt-
../data/rfc/rfc3957.txt-Abstract
../data/rfc/rfc3957.txt-
../data/rfc/rfc3957.txt: Authentication, Authorization, and Accounting (AAA) servers, such as
../data/rfc/rfc3957.txt- RADIUS and DIAMETER, are in use within the Internet today to provide
../data/rfc/rfc3957.txt- authentication and authorization services for dial-up computers.
../data/rfc/rfc3957.txt- Mobile IP for IPv4 requires strong authentication between the mobile
../data/rfc/rfc3957.txt- node and its home agent. When the mobile node shares an AAA Security
../data/rfc/rfc3957.txt- Association with its home AAA server, however, it is possible to use
--
../data/rfc/rfc3957.txt-
../data/rfc/rfc3957.txt- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
../data/rfc/rfc3957.txt- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
../data/rfc/rfc3957.txt- document are to be interpreted as described in [4].
../data/rfc/rfc3957.txt-
../data/rfc/rfc3957.txt: AAA Authentication, Authorization, and Accounting (see
../data/rfc/rfc3957.txt- [10]).
../data/rfc/rfc3957.txt-
../data/rfc/rfc3957.txt- AAA entity A network node processing AAA messages according to the
../data/rfc/rfc3957.txt- requirements for AAA protocols (see [10]).
../data/rfc/rfc3957.txt-
--
../data/rfc/rfc3957.txt- Security Association with its home agent, perhaps because it does not
../data/rfc/rfc3957.txt- yet have a home address [5]. The protocol and messages in this
../data/rfc/rfc3957.txt- document are intended to facilitate the following operations which
../data/rfc/rfc3957.txt- may occur between the mobile node, foreign agent, home agent, and AAA
../data/rfc/rfc3957.txt- servers in the visited (local) domain (Authentication, Authorization
../data/rfc/rfc3957.txt: and Accounting Local or AAAL) and in the home domain (Authentication,
../data/rfc/rfc3957.txt: Authorization, and Accounting Home or AAAH). In the following
../data/rfc/rfc3957.txt- sequence of messages, the only message flows specified in this
../data/rfc/rfc3957.txt- document are the Registration Request between the mobile node and the
../data/rfc/rfc3957.txt- foreign agent, and Registration Reply between the foreign agent and
../data/rfc/rfc3957.txt- the mobile node. The other messages described here result from the
../data/rfc/rfc3957.txt- presumed action of the AAA entities as described in RFC 2977. See
--
../data/rfc/rfc3957.txt-
../data/rfc/rfc3957.txt-11.2. Informative References
../data/rfc/rfc3957.txt-
../data/rfc/rfc3957.txt- [10] Mitton, D., St.Johns, M., Barkley, S., Nelson, D., Patil, B.,
../data/rfc/rfc3957.txt- Stevens, M., and B. Wolff, "Authentication, Authorization, and
../data/rfc/rfc3957.txt: Accounting: Protocol Evaluation", RFC 3127, June 2001.
../data/rfc/rfc3957.txt-
../data/rfc/rfc3957.txt- [11] Rigney, C., Willens, S., Rubens, A., and A. Simpson, "Remote
../data/rfc/rfc3957.txt- Authentication Dial In User Service (RADIUS)", RFC 2865, June
../data/rfc/rfc3957.txt- 2000.
../data/rfc/rfc3957.txt-
../data/rfc/rfc3957.txt- [12] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
../data/rfc/rfc3957.txt- "Diameter Base Protocol", RFC 3588, September 2003.
../data/rfc/rfc3957.txt-
../data/rfc/rfc3957.txt- [13] Glass, S., Hiller, T., Jacobs, S., and C. Perkins, "Mobile IP
../data/rfc/rfc3957.txt: Authentication, Authorization, and Accounting Requirements", RFC
../data/rfc/rfc3957.txt- 2977, October 2000.
../data/rfc/rfc3957.txt-
../data/rfc/rfc3957.txt- [14] Calhoun, P. and C. Perkins, "DIAMETER mobile IP extensions",
../data/rfc/rfc3957.txt- Work in Progress, February 2004.
../data/rfc/rfc3957.txt-
--
../data/rfc/rfc3957.txt- means for the mobile node to belong to the home domain.
../data/rfc/rfc3957.txt-
../data/rfc/rfc3957.txt- Second, from the model illustrated in figure 7 it is clear that AAAL
../data/rfc/rfc3957.txt- and AAAH have to share an IP Security Association, because otherwise
../data/rfc/rfc3957.txt- they could not rely on the authentication results, authorizations,
../data/rfc/rfc3957.txt: nor even the accounting data which might be transacted between them.
../data/rfc/rfc3957.txt- Requiring such bilateral IP Security Associations is, however, in the
../data/rfc/rfc3957.txt- end not scalable; the AAA framework must provide for more scalable
../data/rfc/rfc3957.txt- mechanisms, but the methods by which such a broker model is to be
../data/rfc/rfc3957.txt- created are out of scope for this document. See RFC 2977 for more
../data/rfc/rfc3957.txt- details.
--
../data/rfc/rfc3819.txt- are forwarded on a best-effort basis.
../data/rfc/rfc3819.txt-
../data/rfc/rfc3819.txt- Intserv requires installation of state information in every
../data/rfc/rfc3819.txt- participating router. Performance guarantees cannot be made unless
../data/rfc/rfc3819.txt- this state is present in every router along the path. This, along
../data/rfc/rfc3819.txt: with RSVP processing and the need for usage-based accounting, is
../data/rfc/rfc3819.txt- believed to have scalability problems, particularly in the core of
../data/rfc/rfc3819.txt- the Internet [RFC2208].
../data/rfc/rfc3819.txt-
../data/rfc/rfc3819.txt- IP Differentiated Services (Diffserv) [RFC2475] provides a "toolkit"
../data/rfc/rfc3819.txt- offering coarse-grained controls to aggregates of flows. Diffserv in
--
../data/rfc/rfc3796.txt-5.56. RFC 2496 Definitions of Managed Object for the DS3/E3
../data/rfc/rfc3796.txt- Interface Type
../data/rfc/rfc3796.txt-
../data/rfc/rfc3796.txt- There are no IPv4 dependencies in this specification.
../data/rfc/rfc3796.txt-
../data/rfc/rfc3796.txt:5.57. RFC 2512 Accounting Information for ATM Networks
../data/rfc/rfc3796.txt-
../data/rfc/rfc3796.txt- There are no IPv4 dependencies in this specification.
../data/rfc/rfc3796.txt-
../data/rfc/rfc3796.txt-
../data/rfc/rfc3796.txt-
--
../data/rfc/rfc3796.txt-
../data/rfc/rfc3796.txt-RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
../data/rfc/rfc3796.txt-
../data/rfc/rfc3796.txt-
../data/rfc/rfc3796.txt-5.58. RFC 2513 Managed Objects for Controlling the Collection
../data/rfc/rfc3796.txt: and Storage of Accounting Information for
../data/rfc/rfc3796.txt- Connection-Oriented Networks
../data/rfc/rfc3796.txt-
../data/rfc/rfc3796.txt- There are no IPv4 dependencies in this specification.
../data/rfc/rfc3796.txt-
../data/rfc/rfc3796.txt-5.59. RFC 2514 Definitions of Textual Conventions and
--
../data/rfc/rfc2249.txt- won't be accepted, etc.) vary widely from one MTA to the
../data/rfc/rfc2249.txt- next and cannot be inferred from this variable."
../data/rfc/rfc2249.txt- ::= {mtaEntry 12}
../data/rfc/rfc2249.txt-
../data/rfc/rfc2249.txt--- MTAs typically group inbound reception, queue storage, and
../data/rfc/rfc2249.txt:-- outbound transmission in some way, rather than accounting for
../data/rfc/rfc2249.txt--- such operations only across the MTA as a whole. In the most
../data/rfc/rfc2249.txt--- extreme case separate information will be maintained for each
../data/rfc/rfc2249.txt--- different entity that receives messages and for each entity
../data/rfc/rfc2249.txt--- the MTA stores messages for and delivers messages to. Other
../data/rfc/rfc2249.txt--- MTAs may elect to treat all reception equally, all queue
--
../data/rfc/rfc2977.txt- C. Perkins
../data/rfc/rfc2977.txt- Nokia Research Center
../data/rfc/rfc2977.txt- October 2000
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt: Mobile IP Authentication, Authorization, and Accounting Requirements
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt-Status of this Memo
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt- This memo provides information for the Internet community. It does
../data/rfc/rfc2977.txt- not specify an Internet standard of any kind. Distribution of this
--
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt- Copyright (C) The Internet Society (2000). All Rights Reserved.
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt-Abstract
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt: The Mobile IP and Authentication, Authorization, Accounting (AAA)
../data/rfc/rfc2977.txt- working groups are currently looking at defining the requirements for
../data/rfc/rfc2977.txt: Authentication, Authorization, and Accounting. This document
../data/rfc/rfc2977.txt- contains the requirements which would have to be supported by a AAA
../data/rfc/rfc2977.txt- service to aid in providing Mobile IP services.
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt-1. Introduction
../data/rfc/rfc2977.txt-
--
../data/rfc/rfc2977.txt- users to attach to any domain convenient to their current location.
../data/rfc/rfc2977.txt- In this way, a client needs access to resources being provided by an
../data/rfc/rfc2977.txt- administrative domain different than their home domain (called a
../data/rfc/rfc2977.txt- "foreign domain"). The need for service from a foreign domain
../data/rfc/rfc2977.txt- requires, in many models, Authorization, which leads directly to
../data/rfc/rfc2977.txt: Authentication, and of course Accounting (whence, "AAA"). There is
../data/rfc/rfc2977.txt- some argument which of these leads to, or is derived from the others,
../data/rfc/rfc2977.txt- but there is common agreement that the three AAA functions are
../data/rfc/rfc2977.txt- closely interdependent.
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt-
--
../data/rfc/rfc2977.txt- resources is permitted. The resource may be as simple as a conduit
../data/rfc/rfc2977.txt- to the Internet, or may be as complex as access to specific private
../data/rfc/rfc2977.txt- resources within the foreign domain. Credentials can be exchanged in
../data/rfc/rfc2977.txt- many different ways, all of which are beyond the scope of this
../data/rfc/rfc2977.txt- document. Once authenticated, the mobile user may be authorized to
../data/rfc/rfc2977.txt: access services within the foreign domain. An accounting of the
../data/rfc/rfc2977.txt- actual resources may then be assembled.
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt- Mobile IP is a technology that allows a network node ("mobile node")
../data/rfc/rfc2977.txt- to migrate from its "home" network to other networks, either within
../data/rfc/rfc2977.txt- the same administrative domain, or to other administrative domains.
--
../data/rfc/rfc2977.txt-2. Terminology
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt- This document frequently uses the following terms in addition to
../data/rfc/rfc2977.txt- those defined in RFC 2002 [13]:
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt: Accounting The act of collecting information on resource usage
../data/rfc/rfc2977.txt- for the purpose of trend analysis, auditing, billing,
../data/rfc/rfc2977.txt- or cost allocation.
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt-
--
../data/rfc/rfc2977.txt- to carry out the necessary operations enabling Mobile
../data/rfc/rfc2977.txt- IP registrations. From the point of view of the
../data/rfc/rfc2977.txt- foreign agent, the foreign domain is the local
../data/rfc/rfc2977.txt- domain.
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt: Inter-domain Accounting
../data/rfc/rfc2977.txt: Inter-domain accounting is the collection of
../data/rfc/rfc2977.txt- information on resource usage of an entity with an
../data/rfc/rfc2977.txt- administrative domain, for use within another
../data/rfc/rfc2977.txt: administrative domain. In inter-domain accounting,
../data/rfc/rfc2977.txt: accounting packets and session records will typically
../data/rfc/rfc2977.txt- cross administrative boundaries.
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt-Glass, et al. Informational [Page 3]
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt-RFC 2977 Mobile IP AAA Requirements October 2000
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt: Intra-domain Accounting
../data/rfc/rfc2977.txt: Intra-domain accounting is the collection of
../data/rfc/rfc2977.txt- information on resource within an administrative
../data/rfc/rfc2977.txt- domain, for use within that domain. In intra-domain
../data/rfc/rfc2977.txt: accounting, accounting packets and session records
../data/rfc/rfc2977.txt- typically do not cross administrative boundaries.
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt- Local Domain
../data/rfc/rfc2977.txt- An administrative domain containing the AAA
../data/rfc/rfc2977.txt- infrastructure of immediate interest to a Mobile IP
../data/rfc/rfc2977.txt- client when it is away from home.
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt: Real-time Accounting
../data/rfc/rfc2977.txt: Real-time accounting involves the processing of
../data/rfc/rfc2977.txt- information on resource usage within a defined time
../data/rfc/rfc2977.txt- window. Time constraints are typically imposed in
../data/rfc/rfc2977.txt- order to limit financial risk.
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt- Session record
../data/rfc/rfc2977.txt- A session record represents a summary of the resource
../data/rfc/rfc2977.txt- consumption of a user over the entire session.
../data/rfc/rfc2977.txt: Accounting gateways creating the session record may
../data/rfc/rfc2977.txt: do so by processing interim accounting events.
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt- In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
../data/rfc/rfc2977.txt- "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
../data/rfc/rfc2977.txt- described in [4].
../data/rfc/rfc2977.txt-
--
../data/rfc/rfc2977.txt- the client to belong to the home domain.
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt- Second, from the model illustrated in figure 1 it is clear that AAAL
../data/rfc/rfc2977.txt- and AAAH have to share a security association, because otherwise they
../data/rfc/rfc2977.txt- could not rely on the authentication results, authorizations, nor
../data/rfc/rfc2977.txt: even the accounting data which might be transacted between them.
../data/rfc/rfc2977.txt- Requiring such bilateral security relationships is, however, in the
../data/rfc/rfc2977.txt- end not scalable; the AAA framework MUST provide for more scalable
../data/rfc/rfc2977.txt- mechanisms, as suggested below in section 6.
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt- Finally, in the figure, it is clear that the attendant can naturally
--
../data/rfc/rfc2977.txt- otherwise validating the certificate) so that home and foreign
../data/rfc/rfc2977.txt- agents could avoid a costly online certificate status check.
../data/rfc/rfc2977.txt- - Provide message integrity and identity authentication on a hop-
../data/rfc/rfc2977.txt- by-hop (AAA node) basis.
../data/rfc/rfc2977.txt- - Support replay protection and optional non-repudiation
../data/rfc/rfc2977.txt: capabilities for all authorization and accounting messages. The
../data/rfc/rfc2977.txt: AAA protocol must provide the capability for accounting messages
../data/rfc/rfc2977.txt- to be matched with prior authorization messages.
../data/rfc/rfc2977.txt: - Support accounting via both bilateral arrangements and via broker
../data/rfc/rfc2977.txt: AAA servers providing accounting clearinghouse and reconciliation
../data/rfc/rfc2977.txt- between serving and home networks. There is an explicit agreement
../data/rfc/rfc2977.txt- that if the private network or home ISP authenticates the mobile
../data/rfc/rfc2977.txt- station requesting service, then the private network or home ISP
../data/rfc/rfc2977.txt- network also agrees to reconcile charges with the home service
../data/rfc/rfc2977.txt: provider or broker. Real time accounting must be supported.
../data/rfc/rfc2977.txt: Timestamps must be included in all accounting packets.
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt-4. Requirements related to basic IP connectivity
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt- The requirements listed in the previous section pertain to the
../data/rfc/rfc2977.txt- relationships between the functional units, and don't depend on the
--
../data/rfc/rfc2977.txt- (AAAH) need to interface with the foreign agent and the home agent to
../data/rfc/rfc2977.txt- handle the registration message. Latency would be reduced as a
../data/rfc/rfc2977.txt- result of initial registration being handled in conjunction with AAA
../data/rfc/rfc2977.txt- and the mobile IP mobility agents. Subsequent registrations,
../data/rfc/rfc2977.txt- however, would be handled according to RFC 2002 [13]. Another way to
../data/rfc/rfc2977.txt: reduce latency as to accounting would be the exchange of small
../data/rfc/rfc2977.txt- records.
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt- As there are many different types of sub-services attendants may
../data/rfc/rfc2977.txt: provide to mobile clients, there MUST be extensible accounting
../data/rfc/rfc2977.txt- formats. In this way, the specific services being provided can be
../data/rfc/rfc2977.txt: identified, as well as accounting support should more services be
../data/rfc/rfc2977.txt- identified in the future.
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt- The AAA home domain and the HA home domain of the mobile node need
../data/rfc/rfc2977.txt- not be part of the same administrative domain. Such an situation can
../data/rfc/rfc2977.txt- occur if the home address of the mobile node is provided by one
../data/rfc/rfc2977.txt- domain, e.g., an ISP that the mobile user uses while at home, and the
../data/rfc/rfc2977.txt: authorization and accounting by another (specialized) domain, e.g., a
../data/rfc/rfc2977.txt- credit card company. The foreign agent sends only the authentication
../data/rfc/rfc2977.txt- information of the mobile node to the AAAL, which interfaces to the
../data/rfc/rfc2977.txt- AAAH. After a successful authorization of the mobile node, the
../data/rfc/rfc2977.txt- foreign agent is able to continue with the mobile IP registration
../data/rfc/rfc2977.txt- procedure. Such a scheme introduces more delay if the access to the
--
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt- - authorize the mobile node (once its identity has been established)
../data/rfc/rfc2977.txt- to use at least the set of resources for minimal Mobile IP
../data/rfc/rfc2977.txt- functionality, plus potentially other services requested by the
../data/rfc/rfc2977.txt- mobile node
../data/rfc/rfc2977.txt: - initiate accounting for service utilization
../data/rfc/rfc2977.txt- - use AAA protocol extensions specifically for including Mobile IP
../data/rfc/rfc2977.txt- registration messages as part of the initial registration sequence
../data/rfc/rfc2977.txt- to be handled by the AAA servers.
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt- These tasks, and the resulting more specific tasks to be listed later
--
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt- Assuming that AAAB accepts responsibility for payment to the serving
../data/rfc/rfc2977.txt- domain on behalf of the home domain, the serving domain is assured of
../data/rfc/rfc2977.txt- receiving payments for services offered. However, the redirection
../data/rfc/rfc2977.txt- broker will usually require a copy of authorization messages from the
../data/rfc/rfc2977.txt: home domain and accounting messages from the serving domain, in order
../data/rfc/rfc2977.txt- for the broker to determine if it is willing to accept responsibility
../data/rfc/rfc2977.txt- for the services being authorized and utilized. If the broker does
../data/rfc/rfc2977.txt- not accept such responsibility for any reason, then it must be able
../data/rfc/rfc2977.txt- to terminate service to a mobile node in the serving network. In the
../data/rfc/rfc2977.txt- event that multiple brokers are involved, in most situations all
--
../data/rfc/rfc2977.txt- on foreign agents and AAALs.
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt- Though this mechanism may reduce latency in the transit of messages
../data/rfc/rfc2977.txt- between the domains after the broker has completed its involvement,
../data/rfc/rfc2977.txt- there may be many more messages involved as a result of additional
../data/rfc/rfc2977.txt: copies of authorization and accounting messages to the brokers
../data/rfc/rfc2977.txt- involved. There may also be additional latency for initial access to
../data/rfc/rfc2977.txt- the network, especially when a new security association needs to be
../data/rfc/rfc2977.txt- created between AAAL and AAAH (for example, from the use of ISAKMP).
../data/rfc/rfc2977.txt- These delays may become important factors for latency-critical
../data/rfc/rfc2977.txt- applications.
--
../data/rfc/rfc2977.txt- needed scalability for managing trust relationships between otherwise
../data/rfc/rfc2977.txt- independent network domains. Use of the broker does not preclude
../data/rfc/rfc2977.txt- managing separate trust relationships between domains, but it does
../data/rfc/rfc2977.txt- offer an alternative to doing so. Just as with the AAAH and AAAL
../data/rfc/rfc2977.txt- (see section 5), data specific to Mobile IP control messages MUST NOT
../data/rfc/rfc2977.txt: be processed by the AAAB. Any credentials or accounting data to be
../data/rfc/rfc2977.txt- processed by the AAAB must be present in AAA message units, not
../data/rfc/rfc2977.txt- extracted from Mobile IP protocol extensions.
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt- The following requirements come mostly from [2], which discusses use
../data/rfc/rfc2977.txt- of brokers in the particular case of authorization for roaming dial-
../data/rfc/rfc2977.txt- up users.
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt- - allowing management of trust with external domains by way of
../data/rfc/rfc2977.txt- brokered AAA.
../data/rfc/rfc2977.txt: - accounting reliability. Accounting data that traverses the
../data/rfc/rfc2977.txt: Internet may suffer substantial packet loss. Since accounting
../data/rfc/rfc2977.txt- packets may traverse one or more intermediate authorization points
../data/rfc/rfc2977.txt- (e.g., brokers), retransmission is needed from intermediate points
../data/rfc/rfc2977.txt- to avoid long end-to-end delays.
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt-
--
../data/rfc/rfc2977.txt- [2] for more information on the individual attacks):
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt- + Message editing
../data/rfc/rfc2977.txt- + Attribute editing
../data/rfc/rfc2977.txt- + Theft of shared secrets
../data/rfc/rfc2977.txt: + Theft and modification of accounting data
../data/rfc/rfc2977.txt- + Replay attacks
../data/rfc/rfc2977.txt- + Connection hijacking
../data/rfc/rfc2977.txt: + Fraudulent accounting
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt- These are serious problems which cannot be allowed to persist in any
../data/rfc/rfc2977.txt- acceptable AAA protocol and infrastructure.
../data/rfc/rfc2977.txt-
../data/rfc/rfc2977.txt-7. Security Considerations
--
../data/rfc/rfc3579.txt- Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 46
../data/rfc/rfc3579.txt-
../data/rfc/rfc3579.txt-1. Introduction
../data/rfc/rfc3579.txt-
../data/rfc/rfc3579.txt- The Remote Authentication Dial In User Service (RADIUS) is an
../data/rfc/rfc3579.txt: authentication, authorization and accounting protocol used to control
../data/rfc/rfc3579.txt- network access. RADIUS authentication and authorization is specified
../data/rfc/rfc3579.txt: in [RFC2865], and RADIUS accounting is specified in [RFC2866]; RADIUS
../data/rfc/rfc3579.txt- over IPv6 is specified in [RFC3162].
../data/rfc/rfc3579.txt-
../data/rfc/rfc3579.txt- The Extensible Authentication Protocol (EAP), defined in [RFC2284],
../data/rfc/rfc3579.txt- is an authentication framework which supports multiple authentication
../data/rfc/rfc3579.txt- mechanisms. EAP may be used on dedicated links, switched circuits,
--
../data/rfc/rfc3579.txt- session, with the beginning of the session defined as the
../data/rfc/rfc3579.txt- point where service is first provided and the end of the
../data/rfc/rfc3579.txt- session defined as the point where service is ended. A
../data/rfc/rfc3579.txt- peer may have multiple sessions in parallel or series if
../data/rfc/rfc3579.txt- the NAS supports that, with each session generating a
../data/rfc/rfc3579.txt: separate start and stop accounting record.
../data/rfc/rfc3579.txt-
../data/rfc/rfc3579.txt-2. RADIUS Support for EAP
../data/rfc/rfc3579.txt-
../data/rfc/rfc3579.txt- The Extensible Authentication Protocol (EAP), described in [RFC2284],
../data/rfc/rfc3579.txt- provides a standard mechanism for support of additional
--
../data/rfc/rfc3579.txt-
../data/rfc/rfc3579.txt-
../data/rfc/rfc3579.txt- Although having the NAS send the initial EAP-Request packet has
../data/rfc/rfc3579.txt- substantial advantages, this technique cannot be universally
../data/rfc/rfc3579.txt- employed. There are circumstances in which the peer identity is
../data/rfc/rfc3579.txt: already known (such as when authentication and accounting is handled
../data/rfc/rfc3579.txt- based on Called-Station-Id, Calling-Station-Id and/or
../data/rfc/rfc3579.txt- Originating-Line-Info), but where the appropriate EAP method may vary
../data/rfc/rfc3579.txt- based on that identity.
../data/rfc/rfc3579.txt-
../data/rfc/rfc3579.txt- Rather than sending an initial EAP-Request packet to the
--
../data/rfc/rfc3579.txt- in Access-Request packets, and either NAS-Identifier, NAS-IP-Address
../data/rfc/rfc3579.txt- or NAS-IPv6-Address attributes MUST be included. In order to permit
../data/rfc/rfc3579.txt- forwarding of the Access-Reply by EAP-unaware proxies, if a User-Name
../data/rfc/rfc3579.txt- attribute was included in an Access-Request, the RADIUS server MUST
../data/rfc/rfc3579.txt- include the User-Name attribute in subsequent Access-Accept packets.
../data/rfc/rfc3579.txt: Without the User-Name attribute, accounting and billing becomes
../data/rfc/rfc3579.txt- difficult to manage. The User-Name attribute within the Access-
../data/rfc/rfc3579.txt- Accept packet need not be the same as the User-Name attribute in the
../data/rfc/rfc3579.txt- Access-Request.
../data/rfc/rfc3579.txt-
../data/rfc/rfc3579.txt-
--
../data/rfc/rfc3579.txt-3.3. Table of Attributes
../data/rfc/rfc3579.txt-
../data/rfc/rfc3579.txt- The following table provides a guide to which attributes may be found
../data/rfc/rfc3579.txt- in packets including EAP-Message attribute(s), and in what quantity.
../data/rfc/rfc3579.txt- The EAP-Message and Message-Authenticator attributes specified in
../data/rfc/rfc3579.txt: this document MUST NOT be present in an Accounting-Request. If a
../data/rfc/rfc3579.txt- table entry is omitted, the values found in [RFC2548], [RFC2865],
../data/rfc/rfc3579.txt- [RFC2868], [RFC2869] and [RFC3162] should be assumed.
../data/rfc/rfc3579.txt-
../data/rfc/rfc3579.txt-Request Accept Reject Challenge # Attribute
../data/rfc/rfc3579.txt-0-1 0-1 0 0 1 User-Name
--
../data/rfc/rfc3579.txt- used to provide per-packet confidentiality, authentication, integrity
../data/rfc/rfc3579.txt- and replay protection. IKE SHOULD be used for key management.
../data/rfc/rfc3579.txt-
../data/rfc/rfc3579.txt- Within RADIUS [RFC2865], a shared secret is used for hiding of
../data/rfc/rfc3579.txt- attributes such as User-Password, as well as in computation of the
../data/rfc/rfc3579.txt: Response Authenticator. In RADIUS accounting [RFC2866], the shared
../data/rfc/rfc3579.txt- secret is used in computation of both the Request Authenticator and
../data/rfc/rfc3579.txt- the Response Authenticator.
../data/rfc/rfc3579.txt-
../data/rfc/rfc3579.txt- Since in RADIUS a shared secret is used to provide confidentiality as
../data/rfc/rfc3579.txt- well as integrity protection and authentication, only use of IPsec
--
../data/rfc/rfc3579.txt- from which it can glean peer location information, or which it can
../data/rfc/rfc3579.txt- subject to a known plaintext or offline dictionary attack. To
../data/rfc/rfc3579.txt- address these vulnerabilities, implementations of this specification
../data/rfc/rfc3579.txt- SHOULD use IPsec ESP with non-null transform and per-packet
../data/rfc/rfc3579.txt- encryption, authentication, integrity and replay protection to
../data/rfc/rfc3579.txt: protect both RADIUS authentication [RFC2865] and accounting [RFC2866]
../data/rfc/rfc3579.txt- traffic, as described in Section 4.2.
../data/rfc/rfc3579.txt-
../data/rfc/rfc3579.txt-4.3.2. Spoofing and Hijacking
../data/rfc/rfc3579.txt-
../data/rfc/rfc3579.txt- Access-Request packets with a User-Password attribute establish the
--
../data/rfc/rfc3579.txt- Request Authenticator. However, the Request Authenticator is not a
../data/rfc/rfc3579.txt- replay counter. Since RADIUS servers may not maintain a cache of
../data/rfc/rfc3579.txt- previous Request Authenticators, the Request Authenticator does not
../data/rfc/rfc3579.txt- provide replay protection.
../data/rfc/rfc3579.txt-
../data/rfc/rfc3579.txt: RADIUS accounting [RFC2866] does not support replay protection at the
../data/rfc/rfc3579.txt- protocol level. Due to the need to support failover between RADIUS
../data/rfc/rfc3579.txt: accounting servers, protocol-based replay protection is not
../data/rfc/rfc3579.txt: sufficient to prevent duplicate accounting records. However, once
../data/rfc/rfc3579.txt: accepted by the accounting server, duplicate accounting records can
../data/rfc/rfc3579.txt- be detected by use of the the Acct-Session-Id [RFC2866, section 5.5]
../data/rfc/rfc3579.txt- and Event-Timestamp [RFC2869, section 5.3] attributes.
../data/rfc/rfc3579.txt-
../data/rfc/rfc3579.txt: Unlike RADIUS authentication, RADIUS accounting does not use the
../data/rfc/rfc3579.txt- Request Authenticator as a nonce. Instead, the Request Authenticator
../data/rfc/rfc3579.txt- contains an MD5 hash calculated over the Code, Identifier, Length,
../data/rfc/rfc3579.txt: and request attributes of the Accounting Request packet, plus the
../data/rfc/rfc3579.txt- shared secret. The Response Authenticator also contains an MD5 hash
../data/rfc/rfc3579.txt- calculated over the Code, Identifier and Length, the Request
../data/rfc/rfc3579.txt-
../data/rfc/rfc3579.txt-
../data/rfc/rfc3579.txt-
../data/rfc/rfc3579.txt-Aboba & Calhoun Informational [Page 25]
../data/rfc/rfc3579.txt-
../data/rfc/rfc3579.txt-RFC 3579 RADIUS & EAP September 2003
../data/rfc/rfc3579.txt-
../data/rfc/rfc3579.txt-
../data/rfc/rfc3579.txt: Authenticator field from the Accounting-Request packet being replied
../data/rfc/rfc3579.txt- to, the response attributes and the shared secret.
../data/rfc/rfc3579.txt-
../data/rfc/rfc3579.txt: Since the Accounting Response Authenticator depends in part on the
../data/rfc/rfc3579.txt: Accounting Request Authenticator, it is not possible to replay an
../data/rfc/rfc3579.txt: Accounting-Response unless the Request Authenticator repeats. While
../data/rfc/rfc3579.txt- it is possible to utilize EAP methods such as EAP TLS [RFC2716] which
../data/rfc/rfc3579.txt- include liveness checks on both sides, not all EAP messages will
../data/rfc/rfc3579.txt- include liveness so that this provides incomplete protection.
../data/rfc/rfc3579.txt-
../data/rfc/rfc3579.txt: Strong replay protection for RADIUS authentication and accounting can
../data/rfc/rfc3579.txt- be provided by enabling IPsec replay protection with RADIUS, as
../data/rfc/rfc3579.txt- described in Section 4.2.
../data/rfc/rfc3579.txt-
../data/rfc/rfc3579.txt-4.3.6. Negotiation Attacks
../data/rfc/rfc3579.txt-
--
../data/rfc/rfc3579.txt- 1999.
../data/rfc/rfc3579.txt-
../data/rfc/rfc3579.txt- [RFC2716] Aboba, B. and D. Simon,"PPP EAP TLS Authentication
../data/rfc/rfc3579.txt- Protocol", RFC 2716, October 1999.
../data/rfc/rfc3579.txt-
../data/rfc/rfc3579.txt: [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
../data/rfc/rfc3579.txt-
../data/rfc/rfc3579.txt: [RFC2867] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
../data/rfc/rfc3579.txt- Modifications for Tunnel Protocol Support", RFC 2867,
../data/rfc/rfc3579.txt- June 2000.
../data/rfc/rfc3579.txt-
../data/rfc/rfc3579.txt- [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J.,
../data/rfc/rfc3579.txt- Holdrege, M. and I. Goyret, "RADIUS Attributes for
--
../data/rfc/rfc101.txt-
../data/rfc/rfc101.txt- 3. Host-Host Protocol -- long range study
../data/rfc/rfc101.txt-
../data/rfc/rfc101.txt- 4. Host-Host Protocol -- Short term maintenance and modifications
../data/rfc/rfc101.txt-
../data/rfc/rfc101.txt: 5. Accounting
../data/rfc/rfc101.txt-
../data/rfc/rfc101.txt- 6. Logger Protocol
../data/rfc/rfc101.txt-
../data/rfc/rfc101.txt- 7. Typewriter connection protocol
../data/rfc/rfc101.txt-
--
../data/rfc/rfc101.txt- 1. Improving the current network
../data/rfc/rfc101.txt-
../data/rfc/rfc101.txt- 2. Working on a 316 version of the IMP and as a Terminal Interface
../data/rfc/rfc101.txt- Processor (TIMP)
../data/rfc/rfc101.txt-
../data/rfc/rfc101.txt: 3. Accounting
../data/rfc/rfc101.txt-
../data/rfc/rfc101.txt-
../data/rfc/rfc101.txt-
../data/rfc/rfc101.txt-
../data/rfc/rfc101.txt-Watson [Page 5]
--
../data/rfc/rfc101.txt- raised and G. Grossman of University of Illinois indicated he would
../data/rfc/rfc101.txt- start a dialog on the subject by producing an RFC.
../data/rfc/rfc101.txt-
../data/rfc/rfc101.txt- The question of user names and the meaning of user IDs in socket
../data/rfc/rfc101.txt- numbers was raised. At present socket numbers have no structure, but
../data/rfc/rfc101.txt: several people felt that for accounting, file transfer, and
../data/rfc/rfc101.txt- interprocess communication some structure was probably valuable. A
../data/rfc/rfc101.txt- committee consisting of:
../data/rfc/rfc101.txt-
../data/rfc/rfc101.txt- J. Heafner, RAND (chairman)
../data/rfc/rfc101.txt-
--
../data/rfc/rfc101.txt- link numbers for use in measurements experiments with the network.
../data/rfc/rfc101.txt- Link number 223 was assigned to this function. (Link 223 was later
../data/rfc/rfc101.txt- discovered to be assigned. Link 191 was chosen instead. See RFC
../data/rfc/rfc101.txt- #104, NIC (5768,).
../data/rfc/rfc101.txt-
../data/rfc/rfc101.txt: The problem of accounting was raised as a number of machine or
../data/rfc/rfc101.txt- systems on the network will provide service functions. The present
../data/rfc/rfc101.txt- service facilities being the 360/91 at UCLA, the 360/75 at UCSB, the
../data/rfc/rfc101.txt- NIC at SRI, Multics at MIT, the ILLIAC IV, the 360/67 at Lincoln Lab,
../data/rfc/rfc101.txt- and the Data Machine. The advanced Host-Host protocol study
../data/rfc/rfc101.txt: committee is looking at the accounting problem. There was brief
../data/rfc/rfc101.txt- mention made of a network banking system. Bob Kahn of BBN indicated
../data/rfc/rfc101.txt: that he would start a dialog on the subject of accounting by
../data/rfc/rfc101.txt- producing a paper putting down the issues as he sees them.
../data/rfc/rfc101.txt-
../data/rfc/rfc101.txt- The question was then raised about handling of administrative
../data/rfc/rfc101.txt: procedures such as obtaining accounting numbers on foreign systems.
../data/rfc/rfc101.txt- Dick Watson said he would look into this problem and see how the NIC
../data/rfc/rfc101.txt- can help in its solution.
../data/rfc/rfc101.txt-
../data/rfc/rfc101.txt-
../data/rfc/rfc101.txt-
--
../data/rfc/rfc6765.txt- +---------------+---------------------------------------------------+
../data/rfc/rfc6765.txt- | ifSpeed | Operating data rate for the BCE. For the GBS, it |
../data/rfc/rfc6765.txt- | | is the sum of the current operating data rates of |
../data/rfc/rfc6765.txt- | | all BCEs in the aggregation group, without the |
../data/rfc/rfc6765.txt- | | encapsulation overhead and G.Bond overhead, but |
../data/rfc/rfc6765.txt: | | accounting for Inter-Frame Gaps (IFG). When a |
../data/rfc/rfc6765.txt- | | GBS or a BCE is operating in an asymmetrical |
../data/rfc/rfc6765.txt- | | fashion (the upstream data rate differs from the |
../data/rfc/rfc6765.txt- | | downstream one), the lowest of the values is |
../data/rfc/rfc6765.txt- | | shown. |
../data/rfc/rfc6765.txt- +---------------+---------------------------------------------------+
--
../data/rfc/rfc2699.txt-sufficient detail in RPSL so that low level router configurations can be
../data/rfc/rfc2699.txt-generated from them. RPSL is extensible; new routing protocols and new
../data/rfc/rfc2699.txt-protocol features can be introduced at any time. [STANDARDS-TRACK]
../data/rfc/rfc2699.txt-
../data/rfc/rfc2699.txt-
../data/rfc/rfc2699.txt:2621 Zorn Jun 1999 RADIUS Accounting Server MIB
../data/rfc/rfc2699.txt-
../data/rfc/rfc2699.txt:This memo defines a set of extensions which instrument RADIUS accounting
../data/rfc/rfc2699.txt-server functions. This memo provides information for the Internet
../data/rfc/rfc2699.txt-community.
../data/rfc/rfc2699.txt-
../data/rfc/rfc2699.txt-
../data/rfc/rfc2699.txt:2620 Aboba Jun 1999 RADIUS Accounting Client MIB
../data/rfc/rfc2699.txt-
../data/rfc/rfc2699.txt:This memo defines a set of extensions which instrument RADIUS accounting
../data/rfc/rfc2699.txt-client functions. This memo provides information for the Internet
../data/rfc/rfc2699.txt-community.
../data/rfc/rfc2699.txt-
../data/rfc/rfc2699.txt-
../data/rfc/rfc2699.txt-2619 Zorn Jun 1999 RADIUS Authentication Server MIB
--
../data/rfc/rfc2764.txt- Private dial networks are used to allow remote users to connect into
../data/rfc/rfc2764.txt- an enterprise network using PSTN or Integrated Services Digital
../data/rfc/rfc2764.txt- Network (ISDN) links. Typically, this is done through the deployment
../data/rfc/rfc2764.txt- of Network Access Servers (NASs) at one or more central sites. Users
../data/rfc/rfc2764.txt- dial into such NASs, which interact with Authentication,
../data/rfc/rfc2764.txt: Authorization, and Accounting (AAA) servers to verify the identity of
../data/rfc/rfc2764.txt- the user, and the set of services that the user is authorized to
../data/rfc/rfc2764.txt- receive.
../data/rfc/rfc2764.txt-
../data/rfc/rfc2764.txt- In recent times, as more businesses have found the need for high
../data/rfc/rfc2764.txt- speed Internet connections to their private corporate networks, there
--
../data/rfc/rfc2194.txt- Connection management
../data/rfc/rfc2194.txt- Authentication
../data/rfc/rfc2194.txt- NAS Configuration/Authorization
../data/rfc/rfc2194.txt- Address assignment and routing
../data/rfc/rfc2194.txt- Security
../data/rfc/rfc2194.txt: Accounting
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt- In this document we review existing roaming implementations,
../data/rfc/rfc2194.txt- describing their functionality within this framework. In addition to
../data/rfc/rfc2194.txt- full fledged roaming implementations, we will also review
../data/rfc/rfc2194.txt- implementations that, while not meeting the strict definition of
--
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt- shared use network
../data/rfc/rfc2194.txt- This is an IP dialup network whose use is shared by two or
../data/rfc/rfc2194.txt- more organizations. Shared use networks typically implement
../data/rfc/rfc2194.txt: distributed authentication and accounting in order to
../data/rfc/rfc2194.txt- facilitate the relationship among the sharing parties. Since
../data/rfc/rfc2194.txt- these facilities are also required for implementation of
../data/rfc/rfc2194.txt- roaming, implementation of shared use is frequently a first
../data/rfc/rfc2194.txt- step toward development of roaming capabilities. In fact, one
../data/rfc/rfc2194.txt- of the ways by which a provider may offer roaming service is
--
../data/rfc/rfc2194.txt- between the authentication servers became a problem. In August. 1996,
../data/rfc/rfc2194.txt- AimQuest began development of the AimTraveler Routing Server (ARS) in
../data/rfc/rfc2194.txt- order to improve scalability.
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt- The routing server is comprised of two elements: The Central
../data/rfc/rfc2194.txt: Accounting Server and the Central Routing Server. The Central
../data/rfc/rfc2194.txt: Accounting Server collects all the roaming accounting data for
../data/rfc/rfc2194.txt- settlement. The Central Routing Server manages and maintains
../data/rfc/rfc2194.txt- information on the authentication servers in the roaming consortium.
../data/rfc/rfc2194.txt- Adding, deleting, or updating ISP authentication server information
../data/rfc/rfc2194.txt- (e.g. adding a new member ISP) may be accomplished by editing of a
../data/rfc/rfc2194.txt- configuration file on the Central Routing Server. The configuration
--
../data/rfc/rfc2194.txt- servers, improving speed for repeated queries. The cache is sustained
../data/rfc/rfc2194.txt- until a routing server table entry is updated or deleted. Updating
../data/rfc/rfc2194.txt- or deleting results in a message to all neighbor routing servers to
../data/rfc/rfc2194.txt- delete their caches.
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt: The local authentication server also receives the accounting data
../data/rfc/rfc2194.txt- from the NAS. If the data is for a regular customer login, the data
../data/rfc/rfc2194.txt- is written to the Local ISP AAS log file. If the data is for a
../data/rfc/rfc2194.txt- "roamer," the data is written to three places: the Local ISP AAS log
../data/rfc/rfc2194.txt- file, the Home ISP AAS log file, and the ARS log file.
../data/rfc/rfc2194.txt-
--
../data/rfc/rfc2194.txt- authorized ISP's domain name, authentication servers and other
../data/rfc/rfc2194.txt- information.
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt- The AimTraveler currently supports RADIUS and TACACS+, and could be
../data/rfc/rfc2194.txt- extended to support other authentication protocols. It also receives
../data/rfc/rfc2194.txt: all the accounting records, which are subsequently used as input data
../data/rfc/rfc2194.txt- for billing.
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt- Since ISPs' NAS devices may be configured differently, the attributes
../data/rfc/rfc2194.txt- returned by the home ISP AAS are discarded.
../data/rfc/rfc2194.txt-
--
../data/rfc/rfc2194.txt- The user's password is hashed with MD5 before being sent from the
../data/rfc/rfc2194.txt- Local ISP AAS to the Home ISP AAS. An encryption key is shared
../data/rfc/rfc2194.txt- between the AAS and ARS. The current version of AimTraveler AAS does
../data/rfc/rfc2194.txt- not support token cards or tunneling protocols.
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt:4.10. Accounting
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt- The AimTraveler Authentication Server (AAS) software can act as
../data/rfc/rfc2194.txt: either a RADIUS or TACACS+ accounting server. When accounting
../data/rfc/rfc2194.txt- information is received from the NAS, the local AimTraveler
../data/rfc/rfc2194.txt: Authentication Server (AAS) sends accounting data (user name, domain
../data/rfc/rfc2194.txt: name, login time) to both the Central Accounting Server (part of the
../data/rfc/rfc2194.txt- ARS) and the user's Home ISP AimTraveler authentication server. In
../data/rfc/rfc2194.txt: the case of GRIC, the Central Accounting Server is run by AimQuest.
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt: The data sent to the central accounting server and home ISP are
../data/rfc/rfc2194.txt- identical except for the form of user id and time stamp. For a
../data/rfc/rfc2194.txt- traveler whose home ISP is in the US, but who is traveling in Japan,
../data/rfc/rfc2194.txt- the Local (Japanese) ISP AimTraveler authentication server will
../data/rfc/rfc2194.txt: receive an accounting record timestamped with Japan time while the
../data/rfc/rfc2194.txt- Home (US) ISP AimTraveler authentication server will receive an
../data/rfc/rfc2194.txt: accounting record timestamped with the appropriate US timezone.
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt: The accounting data includes 2 new attributes for settlement
../data/rfc/rfc2194.txt- reporting:
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt- Attribute Number Type
../data/rfc/rfc2194.txt- --------- ------ ----
../data/rfc/rfc2194.txt-
--
../data/rfc/rfc2194.txt- and London. More information on i-Pass can be obtained from
../data/rfc/rfc2194.txt- http://www.ipass.com.
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt- The i-Pass network consists of a number of servers that provide
../data/rfc/rfc2194.txt- real-time authentication services to partner ISPs. Authentication
../data/rfc/rfc2194.txt: requests and accounting records for roaming users are encrypted and
../data/rfc/rfc2194.txt- sent to an i-Pass serverwhere they are logged, and then forwarded to
../data/rfc/rfc2194.txt- a home ISP for authentication and/or logging.
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt: Periodically, i-Pass reconciles all accounting records, generates
../data/rfc/rfc2194.txt- billing statements, and acts as a single point for collecting and
../data/rfc/rfc2194.txt- remitting payments.
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt- i-Pass provides its service only to ISPs and channel partners. It
../data/rfc/rfc2194.txt- does not attempt to establish a business relationship with
--
../data/rfc/rfc2194.txt- ISPs may chooe to provide authentication for their end-users roaming
../data/rfc/rfc2194.txt- elsewhere, but not to provide access points to the i-Pass network.
../data/rfc/rfc2194.txt- In this case the software integration effort is greatly reduced and
../data/rfc/rfc2194.txt- can be as little as 1/2 a man-day.
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt:5.5. Accounting
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt: Accounting transactions are handled in the same way as authentication
../data/rfc/rfc2194.txt- requests. In addition to being logged at the i-Pass servers,
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt-Aboba, et. al. Informational [Page 11]
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt-RFC 2194 Review of Roaming Implementations September 1997
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt: accounting transactions are sent in real-time to the home ISP. This
../data/rfc/rfc2194.txt- is intended to allow ISPs to update users' credit limit information
../data/rfc/rfc2194.txt- on a real-time basis (to the extent that this capability is supported
../data/rfc/rfc2194.txt: by their billing and accounting systems).
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt- Settlement is performed monthly. The settlement process involves
../data/rfc/rfc2194.txt- calculating the costs associated with each individual session, and
../data/rfc/rfc2194.txt- aggregating them for each ISP. A net amount is then calculated which
../data/rfc/rfc2194.txt- is either due from i-Pass to the ISP, or from the ISP to i-Pass,
--
../data/rfc/rfc2194.txt-Aboba, et. al. Informational [Page 14]
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt-RFC 2194 Review of Roaming Implementations September 1997
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt:6.6. Accounting
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt: Accounting information is transferred between the local RADIUS
../data/rfc/rfc2194.txt: accounting proxy/server and home RADIUS accounting server. Every day
../data/rfc/rfc2194.txt: each node sends a summary accounting information record to a central
../data/rfc/rfc2194.txt- server in order to support nationwide settlement. The central server
../data/rfc/rfc2194.txt- is run by the central Data Communication Bureau of China Telecom.
../data/rfc/rfc2194.txt- Every month the central server sends the settlement bill to the
../data/rfc/rfc2194.txt- provincial ISPs.
../data/rfc/rfc2194.txt-
--
../data/rfc/rfc2194.txt-Aboba, et. al. Informational [Page 22]
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt-RFC 2194 Review of Roaming Implementations September 1997
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt:7.11. Accounting
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt: In the MSN roaming implementation, the accounting data exchange
../data/rfc/rfc2194.txt: process is specified in terms of an accounting record format, and a
../data/rfc/rfc2194.txt- method by which the records are transferred from the partners to MSN,
../data/rfc/rfc2194.txt- which acts as the settlement agent. Defining the interaction in
../data/rfc/rfc2194.txt- terms of record formats and transfer protocols implies that the
../data/rfc/rfc2194.txt- partners do not communicate with the settlement agent using NAS
../data/rfc/rfc2194.txt: accounting protocols. As a result, accounting protocol
../data/rfc/rfc2194.txt- interoperability is not be required.
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt- However, for this advantage to be fully realized, it is necessary for
../data/rfc/rfc2194.txt: the accounting record format to be extensible. This makes it more
../data/rfc/rfc2194.txt- likely that the format can be adapted for use with the wide variety
../data/rfc/rfc2194.txt: of accounting protocols in current use (such as SNMP, syslog, RADIUS,
../data/rfc/rfc2194.txt- and TACACS+), as well as future protocols. After all, if the record
../data/rfc/rfc2194.txt- format cannot express the metrics provided by a particular partner's
../data/rfc/rfc2194.txt: accounting protocol, then the record format will not be of much
../data/rfc/rfc2194.txt- usefor a heterogeneous roaming consortium.
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt:7.11.1. Accounting record format
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt- The Microsoft RADIUS proxy/server supports the ability to customize
../data/rfc/rfc2194.txt: the accounting record format, and it is expected that some ISPs will
../data/rfc/rfc2194.txt- make use of this capability. However for those who want to use it
../data/rfc/rfc2194.txt: "off the shelf" a default accounting record format is provided. The
../data/rfc/rfc2194.txt: accounting record includes information provided by RADIUS:
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt- User Name (String; the user's ID, including prefix or suffix)
../data/rfc/rfc2194.txt- NAS IP address (Integer; the IP address of the user's NAS)
../data/rfc/rfc2194.txt- NAS Port (Integer; identifies the physical port on the NAS)
../data/rfc/rfc2194.txt- Service Type (Integer; identifies the service provided to the user)
../data/rfc/rfc2194.txt- NAS Identifier (Integer; unique identifier for the NAS)
../data/rfc/rfc2194.txt- Status Type (Integer; indicates session start and stop,
../data/rfc/rfc2194.txt: as well as accounting on and off)
../data/rfc/rfc2194.txt- Delay Time (Integer; time client has been trying to send)
../data/rfc/rfc2194.txt- Input Octets (Integer; in stop record, octets received from port)
../data/rfc/rfc2194.txt- Output Octets (Integer; in stop record, octets sent to port)
../data/rfc/rfc2194.txt- Session ID (Integer; unique ID linking start and stop records)
../data/rfc/rfc2194.txt- Authentication (Integer; indicates how user was authenticated)
--
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt- However, since this default format is not extensible, it cannot
../data/rfc/rfc2194.txt- easily be adapted to protocols other than RADIUS, services other than
../data/rfc/rfc2194.txt- dialup (i.e. dedicated connections) or rated events (i.e. file
../data/rfc/rfc2194.txt- downloads). This is a serious limitation, and as a result, customers
../data/rfc/rfc2194.txt: have requested a more general accounting record format.
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt-7.11.2. Transfer mechanism
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt: Prior to being transferred, the accounting records are compressed so
../data/rfc/rfc2194.txt: as to save bandwidth. The transfer of accounting records is handled
../data/rfc/rfc2194.txt- via FTP, with the transfer being initiated by the receiving party,
../data/rfc/rfc2194.txt- rather than by the sending party. A duplicate set of records is kept
../data/rfc/rfc2194.txt- by the local ISP for verification purposes.
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt-8. Merit Network Implementation
--
../data/rfc/rfc2194.txt- qualified domain name. Users accessing the shared dial-in service
../data/rfc/rfc2194.txt- identify themselves by using a MichNet AccessID which consists of
../data/rfc/rfc2194.txt- their local id concatenated with "@" followed by the realm-name -
../data/rfc/rfc2194.txt- e.g. user@realm
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt: Merit operates a set of Authentication, Authorization and Accounting
../data/rfc/rfc2194.txt- (AAA) servers supporting the RADIUS protocol which are called core
../data/rfc/rfc2194.txt- servers. The core servers support all the dial-in service sites and
../data/rfc/rfc2194.txt- act as proxy servers to other AAA servers running at the
../data/rfc/rfc2194.txt- participating organizations. For security reasons, Merit staff run
../data/rfc/rfc2194.txt- all core servers; in particular, the user password is in the clear
--
../data/rfc/rfc2194.txt-8.1.2. MichNet National and International Dial-In Services
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt- In addition to the MichNet shared dial-in service, Merit also
../data/rfc/rfc2194.txt- provides access from locations outside of Michigan by interconnecting
../data/rfc/rfc2194.txt- with other dial-in services. These services are typically billed by
../data/rfc/rfc2194.txt: connect time. Merit acts as the accounting agent between its member
../data/rfc/rfc2194.txt- and affiliate organizations and the outside service provider.
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt- The services currently supported are a national 800 number and
../data/rfc/rfc2194.txt- service via the ADP/Autonet dial-in network. Connection with
../data/rfc/rfc2194.txt- IBM/Advantis is being tested, and several other service interconnects
../data/rfc/rfc2194.txt- are being investigated.
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt- Calls placed by a Merit member/affiliate user to these external
../data/rfc/rfc2194.txt- dial-in services are authenticated by having each of those services
../data/rfc/rfc2194.txt: forward RADIUS authentication requests and accounting messages to a
../data/rfc/rfc2194.txt- Merit proxy core server. The core forwards the requests to the
../data/rfc/rfc2194.txt- member/affiliate server for approval. Session records are logged at
../data/rfc/rfc2194.txt- the Merit core server and at the member/affiliate erver. Merit bills
../data/rfc/rfc2194.txt: members/affiliates monthly, based on processing of the accounting
../data/rfc/rfc2194.txt- logs. The members and affiliates are responsible for rebilling their
../data/rfc/rfc2194.txt- users.
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt- The Merit AAA software supports the ability to request positive
../data/rfc/rfc2194.txt- confirmation of acceptance of charges, and provides tools for
--
../data/rfc/rfc2194.txt- institutions have control in defining authorization rules. Currently
../data/rfc/rfc2194.txt- authorization may be done using any combination of the user's group
../data/rfc/rfc2194.txt- status and user's account status. A set of programming interfaces is
../data/rfc/rfc2194.txt- also provided for incorporating new authorization policies.
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt:8.3. Accounting
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt- In the Merit AAA server, a session is defined as starting from the
../data/rfc/rfc2194.txt- moment the user connects to the NAS, and ending at the point when the
../data/rfc/rfc2194.txt- user disconnects. During the course of a session, both the core
../data/rfc/rfc2194.txt- server and the home server maintain status information about the
--
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt- available tokens, or to limit number of simultaneous sessions for a
../data/rfc/rfc2194.txt- given AccessID. Information such as whether the session is for a
../data/rfc/rfc2194.txt- guest, whether it used a token, and other information is included
../data/rfc/rfc2194.txt: with the accounting stop information when it is logged. Merit has
../data/rfc/rfc2194.txt- made enhancements to the RADIUS protocol, that are local to the AAA
../data/rfc/rfc2194.txt- server, to support maintenance of session status information.
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt- When a user session is successfully authenticated, the NAS sends out
../data/rfc/rfc2194.txt: a RADIUS accounting start request to the core server. The core server
../data/rfc/rfc2194.txt- forwards that request to the user's home server. The home server
../data/rfc/rfc2194.txt- updates the status of the session and then responds to the core. The
../data/rfc/rfc2194.txt: core server in turn responds to the NAS. In the accounting Start
../data/rfc/rfc2194.txt- request, a NAS conforming to the RADIUS specification must return the
../data/rfc/rfc2194.txt- Class attribute and value it received in the Access-Accept for the
../data/rfc/rfc2194.txt- session, thus sending back the dial-in session identifier created by
../data/rfc/rfc2194.txt- the session's home server.
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt: When a user ends a session, an accounting stop request is sent
../data/rfc/rfc2194.txt- through the same path. the same path. The dial-in session
../data/rfc/rfc2194.txt- identifier is again returned by the NAS, providing a means of
../data/rfc/rfc2194.txt- uniquely identifying a session. By configuring the finite state
../data/rfc/rfc2194.txt: machine in each of the AAA servers, any accounting requests may be
../data/rfc/rfc2194.txt: logged by any of the servers where the accounting requests are
../data/rfc/rfc2194.txt- received.
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt- Because the same session logs are available on every server in the
../data/rfc/rfc2194.txt: path of a session's authorization and accounting message, problems
../data/rfc/rfc2194.txt- with reconciliation of specific sessions may be resolved easily. For
../data/rfc/rfc2194.txt- the shared dial-in service, there are no usage charges. Merit has
../data/rfc/rfc2194.txt- tools to verify that organizations do not authorize more guest
../data/rfc/rfc2194.txt- sessions than the number of SATs allocated to the organization. For
../data/rfc/rfc2194.txt- surcharged sessions, Merit sends each organization a summary bill
--
../data/rfc/rfc2194.txt- between systems. Such authenticated sessions are particularly
../data/rfc/rfc2194.txt- important between the local, regional and zone coordinators who
../data/rfc/rfc2194.txt- handle preparation and transmission of the Nodediffs. A single shared
../data/rfc/rfc2194.txt- secret is used per system.
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt:9.6. Accounting
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt: Within FidoNet, the need for accounting arises primarily from the
../data/rfc/rfc2194.txt- need of local, regional and zone coordinators to be reimbursed for
../data/rfc/rfc2194.txt- their expenses. In order to support this, utilities have been
../data/rfc/rfc2194.txt- developed to account for network usage at the system level according
../data/rfc/rfc2194.txt: to various metrics. However, the accounting techniques are not
../data/rfc/rfc2194.txt- applied at the user level. Distributed authentication and acounting
../data/rfc/rfc2194.txt- are not implemented and therefore users may not roam between systems.
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt-10. Acknowledgements
../data/rfc/rfc2194.txt-
--
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt- [9] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote
../data/rfc/rfc2194.txt- Authentication Dial In User Service (RADIUS)", RFC 2058, Livingston,
../data/rfc/rfc2194.txt- Merit, Daydreamer, January 1997.
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt: [10] Rigney, C., "RADIUS Accounting", RFC 2059, Livingston, January
../data/rfc/rfc2194.txt- 1997.
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt-
../data/rfc/rfc2194.txt-
--
../data/rfc/rfc5067.txt- PLMN, provided that an access point of some type to the destination
../data/rfc/rfc5067.txt- service provider's network is available on the Internet. There is
../data/rfc/rfc5067.txt- also no guarantee that the originating service provider querying
../data/rfc/rfc5067.txt- infrastructure ENUM is able to access the ingress network element of
../data/rfc/rfc5067.txt- the destination provider's network. Additional peering and
../data/rfc/rfc5067.txt: accounting agreements requiring authentication may be necessary. The
../data/rfc/rfc5067.txt- access provided may also be to a shared network of a group of
../data/rfc/rfc5067.txt- providers, resolving the final destination network within the shared
../data/rfc/rfc5067.txt- network.
../data/rfc/rfc5067.txt-
../data/rfc/rfc5067.txt-
--
../data/rfc/rfc5931.txt-
../data/rfc/rfc5931.txt-RFC 5931 EAP Password August 2010
../data/rfc/rfc5931.txt-
../data/rfc/rfc5931.txt-
../data/rfc/rfc5931.txt- [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
../data/rfc/rfc5931.txt: Authorization, and Accounting (AAA) Key Management",
../data/rfc/rfc5931.txt- BCP 132, RFC 4962, July 2007.
../data/rfc/rfc5931.txt-
../data/rfc/rfc5931.txt- [RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman
../data/rfc/rfc5931.txt- Groups for Use with IETF Standards", RFC 5114,
../data/rfc/rfc5931.txt- January 2008.
--
../data/rfc/rfc6155.txt- an authenticated and authorized third-party requestor, it can treat
../data/rfc/rfc6155.txt- this request as a location configuration request.
../data/rfc/rfc6155.txt-
../data/rfc/rfc6155.txt- After receiving a location request that includes an NAI, the LIS
../data/rfc/rfc6155.txt- sends a "Location-Requestor-Authentication-Protocol" access request
../data/rfc/rfc6155.txt: message to the Authentication, Authorization, and Accounting (AAA)
../data/rfc/rfc6155.txt- server. This request includes an "MS-Identity-Assertion" parameter
../data/rfc/rfc6155.txt- containing the NAI.
../data/rfc/rfc6155.txt-
../data/rfc/rfc6155.txt- The AAA server consults network policy, and if the request is
../data/rfc/rfc6155.txt- permitted, the response includes the IP address that is currently
--
../data/rfc/rfc2501.txt- both bidirectional and unidirectional links.
../data/rfc/rfc2501.txt-
../data/rfc/rfc2501.txt- 2) Bandwidth-constrained, variable capacity links: Wireless links
../data/rfc/rfc2501.txt- will continue to have significantly lower capacity than their
../data/rfc/rfc2501.txt- hardwired counterparts. In addition, the realized throughput of
../data/rfc/rfc2501.txt: wireless communications--after accounting for the effects of
../data/rfc/rfc2501.txt- multiple access, fading, noise, and interference conditions,
../data/rfc/rfc2501.txt- etc.--is often much less than a radio's maximum transmission rate.
../data/rfc/rfc2501.txt-
../data/rfc/rfc2501.txt- One effect of the relatively low to moderate link capacities is
../data/rfc/rfc2501.txt- that congestion is typically the norm rather than the exception,
--
../data/rfc/rfc2501.txt-
../data/rfc/rfc2501.txt- 3) Topological rate of change--the speed with which a network's
../data/rfc/rfc2501.txt- topology is changing
../data/rfc/rfc2501.txt-
../data/rfc/rfc2501.txt- 4) Link capacity--effective link speed measured in bits/second,
../data/rfc/rfc2501.txt: after accounting for losses due to multiple access, coding,
../data/rfc/rfc2501.txt- framing, etc.
../data/rfc/rfc2501.txt-
../data/rfc/rfc2501.txt- 5) Fraction of unidirectional links--how effectively does a
../data/rfc/rfc2501.txt- protocol perform as a function of the presence of unidirectional
../data/rfc/rfc2501.txt- links?
--
../data/rfc/rfc5058.txt-
../data/rfc/rfc5058.txt- - Destination unawareness: When a multicast packet arrives in a
../data/rfc/rfc5058.txt- router, the router can determine the next hops for the packet,
../data/rfc/rfc5058.txt- but knows nothing about the ultimate destinations of the packet,
../data/rfc/rfc5058.txt- nor about how many times the packet will be duplicated later on
../data/rfc/rfc5058.txt: in the network. This complicates the security, accounting and
../data/rfc/rfc5058.txt- policy functions.
../data/rfc/rfc5058.txt-
../data/rfc/rfc5058.txt- In addition to the Host Group model, a routing algorithm is required
../data/rfc/rfc5058.txt- to maintain the member state and the delivery tree. This can be done
../data/rfc/rfc5058.txt- using a (truncated) broadcast algorithm or a multicast algorithm
--
../data/rfc/rfc5058.txt- implementations, this is on a polling basis, yielding a slower
../data/rfc/rfc5058.txt- reaction to, e.g., link failures. It may also take some time for
../data/rfc/rfc5058.txt- traditional IP multicast routing protocols to fix things up if
../data/rfc/rfc5058.txt- there is a large number of groups that need to be fixed.
../data/rfc/rfc5058.txt-
../data/rfc/rfc5058.txt: 7) Easy security and accounting. In contrast with the Host Group
../data/rfc/rfc5058.txt- Model, in Xcast all the sources know the members of the multicast
../data/rfc/rfc5058.txt- channel, which gives the sources the means to, e.g., reject
../data/rfc/rfc5058.txt- certain members or count the traffic going to certain members
../data/rfc/rfc5058.txt- quite easily. Not only a source, but also a border router is able
../data/rfc/rfc5058.txt- to determine how many times a packet will be duplicated in its
--
../data/rfc/rfc5975.txt- obey the rule that over all time periods, the amount of data sent
../data/rfc/rfc5975.txt- cannot exceed MPS+min[pT, rT+b-MPS], where r and b are the token
../data/rfc/rfc5975.txt- bucket parameters, MPS is the maximum packet size, and T is the
../data/rfc/rfc5975.txt- length of the time period (note that when p is infinite, this reduces
../data/rfc/rfc5975.txt- to the standard token bucket requirement). For the purposes of this
../data/rfc/rfc5975.txt: accounting, links MUST count packets that are smaller than the
../data/rfc/rfc5975.txt- minimum policing unit as being of size m. Packets that arrive at an
../data/rfc/rfc5975.txt- element and cause a violation of the MPS + min[pT, rT+b-MPS] bound
../data/rfc/rfc5975.txt- are considered non-conformant.
../data/rfc/rfc5975.txt-
../data/rfc/rfc5975.txt- All 5 of the sub-parameters MUST be included in the TMOD parameter.
--
../data/rfc/rfc7593.txt-
../data/rfc/rfc7593.txt-
../data/rfc/rfc7593.txt-5. Abuse Prevention and Incident Handling
../data/rfc/rfc7593.txt-
../data/rfc/rfc7593.txt- Since the eduroam service is a confederation of autonomous networks,
../data/rfc/rfc7593.txt: there is little justification for transferring accounting information
../data/rfc/rfc7593.txt- from the Service Provider to any other (in general) or to the
../data/rfc/rfc7593.txt: Identity Provider of the user (in particular). Accounting in eduroam
../data/rfc/rfc7593.txt- is therefore considered to be a local matter of the Service Provider.
../data/rfc/rfc7593.txt- The eduroam compliance statement [eduroam-compliance] in fact
../data/rfc/rfc7593.txt: specifies that accounting traffic [RFC5280] SHOULD NOT be forwarded.
../data/rfc/rfc7593.txt-
../data/rfc/rfc7593.txt- The static routing infrastructure of eduroam acts as a filtering
../data/rfc/rfc7593.txt: system blocking accounting traffic from misconfigured local RADIUS
../data/rfc/rfc7593.txt: servers. Proxy servers are configured to terminate accounting
../data/rfc/rfc7593.txt: request traffic by answering to Accounting-Requests with an
../data/rfc/rfc7593.txt: Accounting-Response in order to prevent the retransmission of
../data/rfc/rfc7593.txt: orphaned Accounting-Request messages. With dynamic discovery,
../data/rfc/rfc7593.txt- Identity Providers that are discoverable via DNS will need to apply
../data/rfc/rfc7593.txt- these filtering measures themselves. This is an increase in
../data/rfc/rfc7593.txt- complexity of the Identity Provider RADIUS configuration.
../data/rfc/rfc7593.txt-
../data/rfc/rfc7593.txt- Roaming creates accountability problems, as identified by [RFC4372]
--
../data/rfc/rfc7593.txt-
../data/rfc/rfc7593.txt-
../data/rfc/rfc7593.txt-5.3. Chargeable User Identity
../data/rfc/rfc7593.txt-
../data/rfc/rfc7593.txt- The Chargeable-User-Identity (CUI) attribute is defined by RFC 4372
../data/rfc/rfc7593.txt: [RFC4372] as an answer to accounting problems caused by the use of
../data/rfc/rfc7593.txt- anonymous identity in some EAP methods. In eduroam, the primary use
../data/rfc/rfc7593.txt- of CUI is in incident handling, but it can also enhance local
../data/rfc/rfc7593.txt: accounting.
../data/rfc/rfc7593.txt-
../data/rfc/rfc7593.txt- The eduroam policy requires that a given user's CUI generated for
../data/rfc/rfc7593.txt- requests originating from different sites should be different (to
../data/rfc/rfc7593.txt- prevent collusion attacks). The eduroam policy thus mandates that a
../data/rfc/rfc7593.txt- CUI request be accompanied by the Operator-Name attribute, which is
--
../data/rfc/rfc7593.txt- implementations; therefore, the only solution was moving all CUI
../data/rfc/rfc7593.txt- support to the RADIUS server.
../data/rfc/rfc7593.txt-
../data/rfc/rfc7593.txt- CUI request generation requires only the addition of NUL CUI
../data/rfc/rfc7593.txt- attributes to outgoing Access-Requests; however, the real strength of
../data/rfc/rfc7593.txt: CUI comes with accounting. Implementation of CUI-based accounting in
../data/rfc/rfc7593.txt: the server requires that the authentication and accounting RADIUS
../data/rfc/rfc7593.txt- servers used directly by the NAS are actually the same or at least
../data/rfc/rfc7593.txt- have access to a common source of information. Upon processing of an
../data/rfc/rfc7593.txt- Access-Accept, the authenticating RADIUS server must store the
../data/rfc/rfc7593.txt- received CUI value together with the device's Calling-Station-Id in a
../data/rfc/rfc7593.txt: temporary database. Upon receipt of an Accounting-Request, the
../data/rfc/rfc7593.txt- server needs to update the packet with the CUI value read from the
../data/rfc/rfc7593.txt- database.
../data/rfc/rfc7593.txt-
../data/rfc/rfc7593.txt- A wide introduction of CUI support in eduroam will significantly
../data/rfc/rfc7593.txt- simplify incident handling at Service Providers. Introducing local,
--
../data/rfc/rfc923.txt- 1-149 Unassigned [JBP]
../data/rfc/rfc923.txt- 150 Xerox NS IDP [109,LLG]
../data/rfc/rfc923.txt- 151 Unassigned [JBP]
../data/rfc/rfc923.txt- 152 PARC Universal Protocol [11,HGM]
../data/rfc/rfc923.txt- 153 TIP Status Reporting [JGH]
../data/rfc/rfc923.txt: 154 TIP Accounting [JGH]
../data/rfc/rfc923.txt- 155 Internet Protocol [regular] [33,77,JBP]
../data/rfc/rfc923.txt- 156-158 Internet Protocol [experimental] [33,77,JBP]
../data/rfc/rfc923.txt- 159 Figleaf Link [JBW1]
../data/rfc/rfc923.txt- 160-195 Unassigned [JBP]
../data/rfc/rfc923.txt- 196-247 Experimental Protocols [JBP]
--
../data/rfc/rfc750.txt- 1 1 Reserved
../data/rfc/rfc750.txt- 2-71 2-107 AHHP Regular Messages [1,3]
../data/rfc/rfc750.txt- 72-151 110-227 Reserved
../data/rfc/rfc750.txt- 152 230 PARC Universal Protocol
../data/rfc/rfc750.txt- 153 231 TIP Status Reporting
../data/rfc/rfc750.txt: 154 232 TIP Accounting
../data/rfc/rfc750.txt- 155-158 233-236 Internet Protocol [35,36,42,43,44]
../data/rfc/rfc750.txt- 159-191 237-277 Measurements [28]
../data/rfc/rfc750.txt- 192-195 300-303 Message Switching Protocol [4,5]
../data/rfc/rfc750.txt- 196-255 304-377 Experimental Protocols
../data/rfc/rfc750.txt- 224-255 340-377 NVP [1,39]
--
../data/rfc/rfc7927.txt-
../data/rfc/rfc7927.txt- infrastructure networks, development of management tools and
../data/rfc/rfc7927.txt- mechanisms must go hand in hand with the rest of the architecture
../data/rfc/rfc7927.txt- design.
../data/rfc/rfc7927.txt-
../data/rfc/rfc7927.txt: Although defining an FCAPS (Fault, Configuration, Accounting,
../data/rfc/rfc7927.txt- Performance, and Security) [ISOIEC-7498-4] management model for ICN
../data/rfc/rfc7927.txt- is clearly outside the scope of this document, there is a need for
../data/rfc/rfc7927.txt- creating basic tools early on while ICN is still in the design and
../data/rfc/rfc7927.txt- experimentation phases that can evolve over time and help network
../data/rfc/rfc7927.txt- operations centers (NOCs) to define policies, validate that they are
../data/rfc/rfc7927.txt- indeed used in practice, be notified early on about failures, and
../data/rfc/rfc7927.txt- determine and resolve configuration problems. Authentication,
../data/rfc/rfc7927.txt: Authorization, and Accounting (AAA) as well as performance
../data/rfc/rfc7927.txt- management, from a NOC perspective, will also need to be considered.
../data/rfc/rfc7927.txt- Given the expectations for a large number of nodes and unprecedented
../data/rfc/rfc7927.txt- traffic volumes, automating tasks or even better employing self-
../data/rfc/rfc7927.txt- management mechanisms are preferred. The main challenge here is that
../data/rfc/rfc7927.txt- all tools we have at our disposal today are node-centric, are end-to-
--
../data/rfc/rfc5472.txt-Table of Contents
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt- 1. Introduction ....................................................4
../data/rfc/rfc5472.txt- 1.1. Terminology ................................................4
../data/rfc/rfc5472.txt- 2. Applications of IPFIX ...........................................4
../data/rfc/rfc5472.txt: 2.1. Accounting .................................................4
../data/rfc/rfc5472.txt- 2.1.1. Example .............................................5
../data/rfc/rfc5472.txt- 2.2. Traffic Profiling ..........................................7
../data/rfc/rfc5472.txt- 2.3. Traffic Engineering ........................................8
../data/rfc/rfc5472.txt- 2.4. Network Security ...........................................9
../data/rfc/rfc5472.txt- 2.5. QoS Monitoring ............................................11
--
../data/rfc/rfc5472.txt- used as basis for the design of the IPFIX protocol. This section
../data/rfc/rfc5472.txt- describes how these target applications can use the IPFIX protocol.
../data/rfc/rfc5472.txt- Considerations for using IPFIX for other applications than those
../data/rfc/rfc5472.txt- described in [RFC3917] can be found in Section 4.1.
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt:2.1. Accounting
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt: Usage-based accounting is one of the target applications for IPFIX as
../data/rfc/rfc5472.txt- defined in [RFC3917]. IPFIX records provide fine-grained measurement
../data/rfc/rfc5472.txt- results for highly flexible and detailed usage reporting. Such data
../data/rfc/rfc5472.txt: is used to realize usage-based accounting. Nevertheless, IPFIX does
../data/rfc/rfc5472.txt- not provide the reliability required by usage-based billing systems
../data/rfc/rfc5472.txt: as defined in [RFC2975] (see Section 4.2). The accounting scenarios
../data/rfc/rfc5472.txt- described in this document only provide limited reliability as
../data/rfc/rfc5472.txt- explained in Section 4.2 and should not be used in environments where
../data/rfc/rfc5472.txt- reliability as demanded by [RFC2975] is mandatory.
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt: In order to realize usage-based accounting with IPFIX, the Flow
../data/rfc/rfc5472.txt: definition has to be chosen in accordance to the accounting purpose,
../data/rfc/rfc5472.txt- such as trend analysis, capacity planning, auditing, or billing and
../data/rfc/rfc5472.txt- cost allocation where some loss of data can be tolerated (see Section
../data/rfc/rfc5472.txt- 4.2).
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt-
--
../data/rfc/rfc5472.txt-RFC 5472 IPFIX Applicability March 2009
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt- Flows can be distinguished by various IEs (e.g., packet header
../data/rfc/rfc5472.txt- fields) from [RFC5102]. Due to the flexible IPFIX Flow definition,
../data/rfc/rfc5472.txt: arbitrary Flow-based accounting models can be realized without
../data/rfc/rfc5472.txt- extensions to the IPFIX protocol.
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt: Accounting can, for instance, be based on individual end-to-end
../data/rfc/rfc5472.txt- Flows. In this case, it can be realized with a Flow definition
../data/rfc/rfc5472.txt- determined by the quintuple consisting of source address
../data/rfc/rfc5472.txt- (sourceIPv4Address), destination address (destinationIPv4Address),
../data/rfc/rfc5472.txt- protocol (protocolIdentifier), and port numbers (udpSourcePort,
../data/rfc/rfc5472.txt: udpDestinationPort). Another example is class-dependent accounting
../data/rfc/rfc5472.txt- (e.g., in a Diffserv network). In this case, Flows could be
../data/rfc/rfc5472.txt- distinguished just by the Diffserv codepoint (DSCP)
../data/rfc/rfc5472.txt- (ipDiffServCodePoint) and IP addresses (sourceIPv4Address,
../data/rfc/rfc5472.txt- destinationIPv4Address). The essential elements needed for
../data/rfc/rfc5472.txt: accounting are the number of transferred packets and bytes per Flow,
../data/rfc/rfc5472.txt- which can be represented by the per-flow counter IEs (e.g.,
../data/rfc/rfc5472.txt- packetTotalCount, octetTotalCount).
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt: For accounting purposes, it would be advantageous to have the ability
../data/rfc/rfc5472.txt: to use IPFIX Flow Records as accounting input in an Authentication,
../data/rfc/rfc5472.txt: Authorization, and Accounting (AAA) infrastructure. AAA servers then
../data/rfc/rfc5472.txt- could provide the mapping between user and Flow information. Again
../data/rfc/rfc5472.txt- for such scenarios the limited reliability currently provided by
../data/rfc/rfc5472.txt- IPFIX has to be taken into account.
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt-2.1.1. Example
--
../data/rfc/rfc5472.txt- required for the target applications described in [RFC3917]
../data/rfc/rfc5472.txt- (M-mandatory, R-recommended, O-optional).
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt- | Application | [RFC5102] | [RFC5477] | additional IEs |
../data/rfc/rfc5472.txt- +-------------+------------+--------------+-----------------+
../data/rfc/rfc5472.txt: | Accounting | M | - | - |
../data/rfc/rfc5472.txt- +-------------+------------+--------------+-----------------+
../data/rfc/rfc5472.txt- | Traffic | M | O | - |
../data/rfc/rfc5472.txt- | Profiling | | | |
../data/rfc/rfc5472.txt- +-------------+------------+--------------+-----------------+
../data/rfc/rfc5472.txt- | Traffic | M | - | O |
--
../data/rfc/rfc5472.txt- +-------------+------------+--------------+-----------------+
../data/rfc/rfc5472.txt- | QoS | M | M | O |
../data/rfc/rfc5472.txt- | Monitoring | |(most metrics)|(derived metrics)|
../data/rfc/rfc5472.txt- +-------------+------------+--------------+-----------------+
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt: For accounting, the IEs in [RFC5102] are sufficient. As mentioned
../data/rfc/rfc5472.txt- above, IPFIX does not conform to the reliability requirements
../data/rfc/rfc5472.txt- demanded by [RFC2975] for usage-based billing systems (see Section
../data/rfc/rfc5472.txt- 4.2). For traffic profiling, additional IEs from [RFC5477] can be
../data/rfc/rfc5472.txt- useful to gain more insight into the traffic. For traffic
../data/rfc/rfc5472.txt- engineering, Flow information from [RFC5102] is sufficient, but it
--
../data/rfc/rfc5472.txt- (see Sections 2.5 and 2.7 for details and references).
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt-3.5. IPFIX and AAA
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt- AAA defines a protocol and architecture for authentication,
../data/rfc/rfc5472.txt: authorization, and accounting for service usage [RFC2903]. The
../data/rfc/rfc5472.txt- DIAMETER protocol [RFC3588] is used for AAA communication, which is
../data/rfc/rfc5472.txt- needed for network access services (Mobile IP, NASREQ, and ROAMOPS).
../data/rfc/rfc5472.txt- The AAA architecture [RFC2903] provides a framework for extending AAA
../data/rfc/rfc5472.txt- support to other services. DIAMETER defines the exchange of messages
../data/rfc/rfc5472.txt- between AAA entities, e.g., between AAA clients at access devices and
../data/rfc/rfc5472.txt- AAA servers, and among AAA servers. DIAMETER is used for the
../data/rfc/rfc5472.txt: transfer of accounting records. In order to form accounting records
../data/rfc/rfc5472.txt: for usage-based accounting measurement, data from the network is
../data/rfc/rfc5472.txt- required. IPFIX defines a protocol to export such data from routers,
../data/rfc/rfc5472.txt- measurement probes, and other devices. Therefore, it looks promising
../data/rfc/rfc5472.txt- to connect those two architectures.
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt- For all scenarios described here, one has to keep in mind that IPFIX
../data/rfc/rfc5472.txt- does not conform to the reliability requirements for usage-based
../data/rfc/rfc5472.txt- billing described in [RFC2975] (see Section 4.2). Using IPFIX
../data/rfc/rfc5472.txt- without reliability extensions together with AAA would result in
../data/rfc/rfc5472.txt: accounting scenarios that do not conform to usage-based billing
../data/rfc/rfc5472.txt- requirements described in [RFC2975].
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt: As shown in Section 2.1, accounting applications can directly
../data/rfc/rfc5472.txt- incorporate an IPFIX Collecting Process to receive IPFIX records with
../data/rfc/rfc5472.txt- information about the transmitted volume. Nevertheless, if a AAA
../data/rfc/rfc5472.txt- infrastructure is in place, the cooperation between IPFIX and AAA
../data/rfc/rfc5472.txt- provides many valuable synergistic benefits. IPFIX records can
../data/rfc/rfc5472.txt: provide the input for AAA accounting functions and provide the basis
../data/rfc/rfc5472.txt: for the generation of DIAMETER accounting records. However, as
../data/rfc/rfc5472.txt- stated in Section 4.2, the use of IPFIX as described in [RFC5101] is
../data/rfc/rfc5472.txt: currently limited to situations where the purpose of the accounting
../data/rfc/rfc5472.txt- does not require reliability.
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt- Further potential features include the mapping of a user ID to Flow
../data/rfc/rfc5472.txt- information (by using authentication information) or using the secure
../data/rfc/rfc5472.txt: authorized exchange of DIAMETER accounting records with neighbor
../data/rfc/rfc5472.txt- domains. The last feature is especially useful in roaming scenarios
../data/rfc/rfc5472.txt- where the user connects to a foreign network and the home provider
../data/rfc/rfc5472.txt- generates the invoice.
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt-
--
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt-3.5.1. Connecting via a AAA Client
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt- One possibility of connecting IPFIX and AAA is to run a AAA client on
../data/rfc/rfc5472.txt: the IPFIX Collector. This client can generate DIAMETER accounting
../data/rfc/rfc5472.txt- messages and send them to a AAA server. The mapping of the Flow
../data/rfc/rfc5472.txt- information to a user ID can be done in the AAA server by using data
../data/rfc/rfc5472.txt: from the authentication process. DIAMETER accounting messages can be
../data/rfc/rfc5472.txt: sent to the accounting application or to other AAA servers (e.g., in
../data/rfc/rfc5472.txt- roaming scenarios).
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt- +---------+ DIAMETER +---------+
../data/rfc/rfc5472.txt- | AAA-S |------------->| AAA-S |
../data/rfc/rfc5472.txt- +---------+ +---------+
--
../data/rfc/rfc5472.txt- between AAA server and service equipment. In this case, the IPFIX
../data/rfc/rfc5472.txt- Collector is part of the ASM. The ASM acts as an interface between
../data/rfc/rfc5472.txt- the IPFIX protocol and the input interface of the AAA server. The
../data/rfc/rfc5472.txt- ASM translates the received IPFIX data into an appropriate format for
../data/rfc/rfc5472.txt- the AAA server. The AAA server then can add information about the
../data/rfc/rfc5472.txt: user ID and generate a DIAMETER accounting record. This accounting
../data/rfc/rfc5472.txt: record can be sent to an accounting application or to other AAA
../data/rfc/rfc5472.txt- servers.
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt- +---------+ DIAMETER +---------+
../data/rfc/rfc5472.txt- | AAA-S |------------->| AAA-S |
../data/rfc/rfc5472.txt- +---------+ +---------+
--
../data/rfc/rfc5472.txt- applications. Application layer acknowledgements are necessary,
../data/rfc/rfc5472.txt- e.g., to inform the Exporter in case the application is not able to
../data/rfc/rfc5472.txt- process the data exported with IPFIX. Such acknowledgements are
../data/rfc/rfc5472.txt- not supported in IPFIX.
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt: Further features like archival accounting and pre-authorization are
../data/rfc/rfc5472.txt- out of scope of the IPFIX specification but need to be realized in
../data/rfc/rfc5472.txt- billing system architectures as described in [RFC2975].
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt-4.3. Using a Different Transport Protocol than SCTP
../data/rfc/rfc5472.txt-
--
../data/rfc/rfc5472.txt- scenarios described in this document. To our current knowledge, the
../data/rfc/rfc5472.txt- usage scenarios proposed in Section 2 do not induce further security
../data/rfc/rfc5472.txt- hazards.
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt- The threat level to IPIFX itself may depend on the usage scenario of
../data/rfc/rfc5472.txt: IPFIX. The usage of IPFIX for accounting or attack detection may
../data/rfc/rfc5472.txt- increase the incentive to attack IPFIX itself. Nevertheless,
../data/rfc/rfc5472.txt- security considerations have to be taken into account in all
../data/rfc/rfc5472.txt- described scenarios.
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt- As described in the security considerations in [RFC5101], security
--
../data/rfc/rfc5472.txt- [RFC2903] de Laat, C., Gross, G., Gommans, L., Vollbrecht, J., and
../data/rfc/rfc5472.txt- D. Spence, "Generic AAA Architecture", RFC 2903, August
../data/rfc/rfc5472.txt- 2000.
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt- [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to
../data/rfc/rfc5472.txt: Accounting Management", RFC 2975, October 2000.
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt- [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
../data/rfc/rfc5472.txt- J., Courtney, W., Davari, S., Firoiu, V., and D.
../data/rfc/rfc5472.txt- Stiliadis, "An Expedited Forwarding PHB (Per-Hop
../data/rfc/rfc5472.txt- Behavior)", RFC 3246, March 2002.
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt- [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September
../data/rfc/rfc5472.txt- 2002.
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt- [RFC3334] Zseby, T., Zander, S., and C. Carle, "Policy-Based
../data/rfc/rfc5472.txt: Accounting", RFC 3334, October 2002.
../data/rfc/rfc5472.txt-
../data/rfc/rfc5472.txt- [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
../data/rfc/rfc5472.txt- Metric for IP Performance Metrics (IPPM)", RFC 3393,
../data/rfc/rfc5472.txt- November 2002.
../data/rfc/rfc5472.txt-
--
../data/rfc/rfc1549.txt- during inter-frame time fill. There is no provision for inter-
../data/rfc/rfc1549.txt- octet time fill.
../data/rfc/rfc1549.txt-
../data/rfc/rfc1549.txt- Mark idle (continuous ones) SHOULD NOT be used for inter-frame
../data/rfc/rfc1549.txt- ill. However, certain types of circuit-switched links require the
../data/rfc/rfc1549.txt: use of mark idle, particularly those that calculate accounting
../data/rfc/rfc1549.txt- based on periods of bit activity. When mark idle is used on a
../data/rfc/rfc1549.txt- bit-synchronous link, the implementation MUST ensure at least 15
../data/rfc/rfc1549.txt- consecutive "1" bits between Flags during the idle period, and
../data/rfc/rfc1549.txt- that the Flag Sequence is always generated at the beginning of a
../data/rfc/rfc1549.txt- frame after an idle period.
--
../data/rfc/rfc6630.txt-
../data/rfc/rfc6630.txt- The following acronyms are used in this document; see the references
../data/rfc/rfc6630.txt- for more details.
../data/rfc/rfc6630.txt-
../data/rfc/rfc6630.txt- AAA
../data/rfc/rfc6630.txt: Authentication, Authorization, and Accounting [RFC3588]
../data/rfc/rfc6630.txt-
../data/rfc/rfc6630.txt- CAP
../data/rfc/rfc6630.txt- Candidate Attachment Point [RFC5836]
../data/rfc/rfc6630.txt-
../data/rfc/rfc6630.txt- DSRK
--
../data/rfc/rfc6630.txt-
../data/rfc/rfc6630.txt- [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
../data/rfc/rfc6630.txt- 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
../data/rfc/rfc6630.txt-
../data/rfc/rfc6630.txt- [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
../data/rfc/rfc6630.txt: Authorization, and Accounting (AAA) Key Management",
../data/rfc/rfc6630.txt- BCP 132, RFC 4962, July 2007.
../data/rfc/rfc6630.txt-
../data/rfc/rfc6630.txt- [RFC5836] Ohba, Y., Wu, Q., and G. Zorn, "Extensible Authentication
../data/rfc/rfc6630.txt- Protocol (EAP) Early Authentication Problem Statement",
../data/rfc/rfc6630.txt- RFC 5836, April 2010.
--
../data/rfc/rfc5661.txt-
../data/rfc/rfc5661.txt-RFC 5661 NFSv4.1 January 2010
../data/rfc/rfc5661.txt-
../data/rfc/rfc5661.txt-
../data/rfc/rfc5661.txt- o A new request, in which the sequence ID is one greater than that
../data/rfc/rfc5661.txt: previously seen in the slot (accounting for sequence wraparound).
../data/rfc/rfc5661.txt- The replier proceeds to execute the new request, and the replier
../data/rfc/rfc5661.txt- MUST increase the slot's sequence ID by one.
../data/rfc/rfc5661.txt-
../data/rfc/rfc5661.txt- o A retransmitted request, in which the sequence ID is equal to that
../data/rfc/rfc5661.txt- currently recorded in the slot. If the original request has
../data/rfc/rfc5661.txt- executed to completion, the replier returns the cached reply. See
../data/rfc/rfc5661.txt- Section 2.10.6.2 for direction on how the replier deals with
../data/rfc/rfc5661.txt- retries of requests that are still in progress.
../data/rfc/rfc5661.txt-
../data/rfc/rfc5661.txt- o A misordered retry, in which the sequence ID is less than
../data/rfc/rfc5661.txt: (accounting for sequence wraparound) that previously seen in the
../data/rfc/rfc5661.txt- slot. The replier MUST return NFS4ERR_SEQ_MISORDERED (as the
../data/rfc/rfc5661.txt- result from SEQUENCE or CB_SEQUENCE).
../data/rfc/rfc5661.txt-
../data/rfc/rfc5661.txt- o A misordered new request, in which the sequence ID is two or more
../data/rfc/rfc5661.txt: than (accounting for sequence wraparound) that previously seen in
../data/rfc/rfc5661.txt- the slot. Note that because the sequence ID MUST wrap around to
../data/rfc/rfc5661.txt- zero once it reaches 0xFFFFFFFF, a misordered new request and a
../data/rfc/rfc5661.txt- misordered retry cannot be distinguished. Thus, the replier MUST
../data/rfc/rfc5661.txt- return NFS4ERR_SEQ_MISORDERED (as the result from SEQUENCE or
../data/rfc/rfc5661.txt- CB_SEQUENCE).
--
../data/rfc/rfc5661.txt- With delegations, a client is able to avoid writing data to the
../data/rfc/rfc5661.txt- server when the CLOSE of a file is serviced. The file close system
../data/rfc/rfc5661.txt- call is the usual point at which the client is notified of a lack of
../data/rfc/rfc5661.txt- stable storage for the modified file data generated by the
../data/rfc/rfc5661.txt- application. At the close, file data is written to the server and,
../data/rfc/rfc5661.txt: through normal accounting, the server is able to determine if the
../data/rfc/rfc5661.txt- available file system space for the data has been exceeded (i.e., the
../data/rfc/rfc5661.txt: server returns NFS4ERR_NOSPC or NFS4ERR_DQUOT). This accounting
../data/rfc/rfc5661.txt- includes quotas. The introduction of delegations requires that an
../data/rfc/rfc5661.txt- alternative method be in place for the same type of communication to
../data/rfc/rfc5661.txt- occur between client and server.
../data/rfc/rfc5661.txt-
../data/rfc/rfc5661.txt- In the delegation response, the server provides either the limit of
--
../data/rfc/rfc5661.txt-
../data/rfc/rfc5661.txt-RFC 5661 NFSv4.1 January 2010
../data/rfc/rfc5661.txt-
../data/rfc/rfc5661.txt-
../data/rfc/rfc5661.txt- support a VALID_SEQID_RANGE value larger than the minimum. The
../data/rfc/rfc5661.txt: maximum VALID_SEQID_RANGE is (2 ^ 32 - 2) (accounting for zero not
../data/rfc/rfc5661.txt- being a valid "seqid" value).
../data/rfc/rfc5661.txt-
../data/rfc/rfc5661.txt- If the server finds the "seqid" is zero, the NFS4ERR_BAD_STATEID
../data/rfc/rfc5661.txt- error is returned to the client. The server further validates the
../data/rfc/rfc5661.txt- "seqid" to ensure it is within the range of parallelism,
--
../data/rfc/rfc5661.txt- o that between different named attribute directories or between a
../data/rfc/rfc5661.txt- named attribute directory and an ordinary directory.
../data/rfc/rfc5661.txt-
../data/rfc/rfc5661.txt- o that between byte-ranges of a file system that the file system
../data/rfc/rfc5661.txt- implementation treats as separate (for example, for space
../data/rfc/rfc5661.txt: accounting purposes), and where cross-connection between the byte-
../data/rfc/rfc5661.txt- ranges are not allowed.
../data/rfc/rfc5661.txt-
../data/rfc/rfc5661.txt-15.1.5. State Management Errors
../data/rfc/rfc5661.txt-
../data/rfc/rfc5661.txt- These errors indicate problems with the stateid (or one of the
--
../data/rfc/rfc5661.txt- The server expects value of csa_sequenceid in the arguments to that
../data/rfc/rfc5661.txt- CREATE_SESSION to be to equal the value of the field eir_sequenceid
../data/rfc/rfc5661.txt- that was returned in results of the EXCHANGE_ID that returned the
../data/rfc/rfc5661.txt- unconfirmed client ID. Before the server replies to that EXCHANGE_ID
../data/rfc/rfc5661.txt- operation, it initializes the client ID slot to be equal to
../data/rfc/rfc5661.txt: eir_sequenceid - 1 (accounting for underflow), and records a
../data/rfc/rfc5661.txt- contrived CREATE_SESSION result with a "cached" result of
../data/rfc/rfc5661.txt- NFS4ERR_SEQ_MISORDERED. With the client ID slot thus initialized,
../data/rfc/rfc5661.txt- the processing of the CREATE_SESSION operation is divided into four
../data/rfc/rfc5661.txt- phases:
../data/rfc/rfc5661.txt-
--
../data/rfc/rfc5661.txt-
../data/rfc/rfc5661.txt- 2. Sequence ID processing. If csa_sequenceid is equal to the
../data/rfc/rfc5661.txt- sequence ID in the client ID's slot, then this is a replay of the
../data/rfc/rfc5661.txt- previous CREATE_SESSION request, and the server returns the
../data/rfc/rfc5661.txt- cached result. If csa_sequenceid is not equal to the sequence ID
../data/rfc/rfc5661.txt: in the slot, and is more than one greater (accounting for
../data/rfc/rfc5661.txt- wraparound), then the server returns the error
../data/rfc/rfc5661.txt- NFS4ERR_SEQ_MISORDERED, and does not change the slot. If
../data/rfc/rfc5661.txt: csa_sequenceid is equal to the slot's sequence ID + 1 (accounting
../data/rfc/rfc5661.txt- for wraparound), then the slot's sequence ID is set to
../data/rfc/rfc5661.txt- csa_sequenceid, and the CREATE_SESSION processing goes to the
../data/rfc/rfc5661.txt- next phase. A subsequent new CREATE_SESSION call over the same
../data/rfc/rfc5661.txt- client ID MUST use a csa_sequenceid that is one greater than the
../data/rfc/rfc5661.txt- sequence ID in the slot.
--
../data/rfc/rfc5661.txt- The value of the sa_sequenceid argument relative to the cached
../data/rfc/rfc5661.txt- sequence ID on the slot falls into one of three cases.
../data/rfc/rfc5661.txt-
../data/rfc/rfc5661.txt- o If the difference between sa_sequenceid and the server's cached
../data/rfc/rfc5661.txt- sequence ID at the slot ID is two (2) or more, or if sa_sequenceid
../data/rfc/rfc5661.txt: is less than the cached sequence ID (accounting for wraparound of
../data/rfc/rfc5661.txt- the unsigned sequence ID value), then the server MUST return
../data/rfc/rfc5661.txt- NFS4ERR_SEQ_MISORDERED.
../data/rfc/rfc5661.txt-
../data/rfc/rfc5661.txt- o If sa_sequenceid and the cached sequence ID are the same, this is
../data/rfc/rfc5661.txt- a retry, and the server replies with what is recorded in the reply
../data/rfc/rfc5661.txt- cache. The lease is possibly renewed as described below.
../data/rfc/rfc5661.txt-
../data/rfc/rfc5661.txt: o If sa_sequenceid is one greater (accounting for wraparound) than
../data/rfc/rfc5661.txt- the cached sequence ID, then this is a new request, and the slot's
../data/rfc/rfc5661.txt- sequence ID is incremented. The operations subsequent to
../data/rfc/rfc5661.txt- SEQUENCE, if any, are processed. If there are no other
../data/rfc/rfc5661.txt- operations, the only other effects are to cache the SEQUENCE reply
../data/rfc/rfc5661.txt- in the slot, maintain the session's activity, and possibly renew
--
../data/rfc/rfc5661.txt- void;
../data/rfc/rfc5661.txt- };
../data/rfc/rfc5661.txt-
../data/rfc/rfc5661.txt-20.9.3. DESCRIPTION
../data/rfc/rfc5661.txt-
../data/rfc/rfc5661.txt: The CB_SEQUENCE operation is used to manage operational accounting
../data/rfc/rfc5661.txt- for the backchannel of the session on which a request is sent. The
../data/rfc/rfc5661.txt- contents include the session ID to which this request belongs, the
../data/rfc/rfc5661.txt- slot ID and sequence ID used by the server to implement session
../data/rfc/rfc5661.txt- request control and exactly once semantics, and exchanged slot ID
../data/rfc/rfc5661.txt- maxima that are used to adjust the size of the reply cache. In each
--
../data/rfc/rfc5661.txt- The value of the csa_sequenceid argument relative to the cached
../data/rfc/rfc5661.txt- sequence ID on the slot falls into one of three cases.
../data/rfc/rfc5661.txt-
../data/rfc/rfc5661.txt- o If the difference between csa_sequenceid and the client's cached
../data/rfc/rfc5661.txt- sequence ID at the slot ID is two (2) or more, or if
../data/rfc/rfc5661.txt: csa_sequenceid is less than the cached sequence ID (accounting for
../data/rfc/rfc5661.txt- wraparound of the unsigned sequence ID value), then the client
../data/rfc/rfc5661.txt- MUST return NFS4ERR_SEQ_MISORDERED.
../data/rfc/rfc5661.txt-
../data/rfc/rfc5661.txt- o If csa_sequenceid and the cached sequence ID are the same, this is
../data/rfc/rfc5661.txt- a retry, and the client returns the CB_COMPOUND request's cached
../data/rfc/rfc5661.txt- reply.
../data/rfc/rfc5661.txt-
../data/rfc/rfc5661.txt: o If csa_sequenceid is one greater (accounting for wraparound) than
../data/rfc/rfc5661.txt- the cached sequence ID, then this is a new request, and the slot's
../data/rfc/rfc5661.txt- sequence ID is incremented. The operations subsequent to
../data/rfc/rfc5661.txt- CB_SEQUENCE, if any, are processed. If there are no other
../data/rfc/rfc5661.txt- operations, the only other effects are to cache the CB_SEQUENCE
../data/rfc/rfc5661.txt- reply in the slot, maintain the session's activity, and when the
--
../data/rfc/rfc6909.txt-RFC 6909 IPv4 Traffic Offload Selector Option April 2013
../data/rfc/rfc6909.txt-
../data/rfc/rfc6909.txt-
../data/rfc/rfc6909.txt- * The local mobility anchor can obtain the offload policy from
../data/rfc/rfc6909.txt- the local configuration store or from a network function such
../data/rfc/rfc6909.txt: as AAA (Authentication, Authorization, and Accounting) or PCRF
../data/rfc/rfc6909.txt- (Policy and Charging Rule Function). The offload policy has to
../data/rfc/rfc6909.txt- be translated to a set of selectors that can be used to match
../data/rfc/rfc6909.txt- the mobile node's IP flows, and these selectors have to be
../data/rfc/rfc6909.txt- carried in the Traffic Selector sub-option. The Traffic
../data/rfc/rfc6909.txt- Selector sub-option MUST be constructed as specified in Section
--
../data/rfc/rfc392.txt-Hicks & Wessler [Page 4]
../data/rfc/rfc392.txt-
../data/rfc/rfc392.txt-RFC 392 Measurement for Transmitting Network Data September 1972
../data/rfc/rfc392.txt-
../data/rfc/rfc392.txt-
../data/rfc/rfc392.txt:Utah-10 Accounting for Network Usage
../data/rfc/rfc392.txt-
../data/rfc/rfc392.txt- for the period 16-SEP-72 12:48:34, ending 19-SEP-72 13:56:11
../data/rfc/rfc392.txt-
../data/rfc/rfc392.txt- Clk Tim Cpu Tim # of Bytes Bits/sec us/bit Load
../data/rfc/rfc392.txt-
--
../data/rfc/rfc392.txt- 04:28 36.32 56362 s 1679.377 80.56 5.52
../data/rfc/rfc392.txt- 02:12 17.71 27120 r 1634.818 81.62 1.73
../data/rfc/rfc392.txt- 06:59 41.88 64333 s 1226.980 81.37 6.66
../data/rfc/rfc392.txt- 37 7.63 12082 r 2552.243 78.97 0.64
../data/rfc/rfc392.txt-
../data/rfc/rfc392.txt:Utah-10 Accounting for Network Usage
../data/rfc/rfc392.txt-
../data/rfc/rfc392.txt- for the period 13-SEP-72 2:23:12, ending 16-SEP-72 11:47:07
../data/rfc/rfc392.txt-
../data/rfc/rfc392.txt- Clk Tim Cpu Tim # of Bytes Bits/sec us/bit Load
../data/rfc/rfc392.txt-
--
../data/rfc/rfc4029.txt-
../data/rfc/rfc4029.txt- "Network and service operation"
../data/rfc/rfc4029.txt- : This is the part of the ISP's network that hosts the
../data/rfc/rfc4029.txt- services required for the correct operation of the
../data/rfc/rfc4029.txt- ISP's network. These services usually include
../data/rfc/rfc4029.txt: management, supervision, accounting, billing, and
../data/rfc/rfc4029.txt- customer management applications.
../data/rfc/rfc4029.txt-
../data/rfc/rfc4029.txt- "Customer connection"
../data/rfc/rfc4029.txt- : This is the part of the network used by a customer
../data/rfc/rfc4029.txt- when connecting to an ISP's network. It includes the
--
../data/rfc/rfc4029.txt-
../data/rfc/rfc4029.txt- - Extend customer management (e.g., RADIUS) mechanisms to be
../data/rfc/rfc4029.txt- able to supply IPv6 prefixes and other information to
../data/rfc/rfc4029.txt- customers.
../data/rfc/rfc4029.txt-
../data/rfc/rfc4029.txt: - Enhance accounting, billing, and so on to work with IPv6 as
../data/rfc/rfc4029.txt- needed. (Note: If dual-stack service is offered, this may
../data/rfc/rfc4029.txt- not be necessary.)
../data/rfc/rfc4029.txt-
../data/rfc/rfc4029.txt- - Implement security for network and service operation.
../data/rfc/rfc4029.txt-
--
../data/rfc/rfc3810.txt- removed. The following points explain this decision.
../data/rfc/rfc3810.txt-
../data/rfc/rfc3810.txt- 1. Routers may want to track per-host multicast listener status on an
../data/rfc/rfc3810.txt- interface. This would allow routers to implement fast leaves
../data/rfc/rfc3810.txt- (e.g., for layered multicast congestion control schemes), as well
../data/rfc/rfc3810.txt: as track listener status for possible security or accounting
../data/rfc/rfc3810.txt- purposes. The present specification does not require routers to
../data/rfc/rfc3810.txt- implement per-host tracking. Nevertheless, the lack of host
../data/rfc/rfc3810.txt- suppression in MLDv2 makes possible to implement either
../data/rfc/rfc3810.txt- proprietary or future standard behavior of multicast routers that
../data/rfc/rfc3810.txt- would support per-host tracking, while being fully interoperable